alexcrichton/rustc-demangle 92
Rust symbol demangling
eddyb/cprep 12
C/C++ preprocessor.
Preparing an RFC on effect polymorphism in Rust with focus on 'const'
Advent of Code solutions in Rust
HTML, CSS, and JS toolkit from Twitter
A simple Minecraft written in Rust with the Piston game engine
1ML prototype interpreter
The Rust package manager
A full featured, fast Command Line Argument Parser for Rust
push eventeddyb/rfcs
commit sha ec42fd0b7fbc0448d1794bfecaa43621eab76814
RFC: mem::black_box and mem::clobber
commit sha 68b4dde8c709a07a8dcdbae9703e26ec6492b10c
black_box stores back to memory, not registers
commit sha 76c213bc535cbac30315a6a6aefaad1530216536
target_feature 1.1
commit sha 54083aa88085767ed0629bcab074eb21bb4c00d9
add perf implications
commit sha 2fec554e5fb428c86f5cac42f61c00bb232e9de7
fmt
commit sha f9d49051d184bf32a36e4efa6c60036756d79ab6
soundness
commit sha 39e03e3da8ca9c47cffed4803550823860685301
fmt
commit sha aa79d09670dda105e9775411caa31bc2d06b2be1
fix bug in reference; add unresolved question about disabling features
commit sha b73fc95e60d6635e012b1eaf52bdd544f1833596
effect system
commit sha 96c3abbf9021551f3cf4fe9a58bf2dfae64b2a78
update effects text
commit sha 48f4616c3d4d4ef7642468a10485a7d2fc9f1cb2
clarify hierarchies
commit sha 800825ccd0f5db7f58a063395dfd02b5b228bb60
msrv
commit sha 4ec9682a9f2c2697eedbdb06350fa5701fd0e862
drawbacks update
commit sha f9057da774a1b5fe4dc33f7658fd89f6d024d083
reviews updates
commit sha a43e9e13055f90b728cdccf46c78a463786806c2
kennytm's review updates
commit sha 00a3022176ce22c4c51e75baefdab8756874fc17
fixes, option addition, wording improvements - fixed typo and RFC link - improved wording a bit - added `--check-msrv-toolchain` option ( @phaylon )
commit sha b0bf8c5d5ba4310db3157dc13459ec1aa562476a
impl_trait_type_aliases
commit sha 1082efdde798691903bd9fc849f6276ac59525a3
Correct some typos and make polymorphic type clearer
commit sha d6db251443e0dd395d9b7ca8810c69dad99d7059
Mention `impl Trait` type aliases in associated types
commit sha c62791c7a0b29d6e52977c9a6648b2b29303c302
Forbid compound `impl Trait` type aliases
push time in 7 hours
pull request commentrust-lang/rust
rustc_mir: track inlined callees in SourceScopeData.
r? @nagisa for LLVM (I wish we had GH teams specifically for review roles so I don't have to guess)
comment created time in 8 hours
push eventeddyb/measureme
commit sha f96d3aa20c9bfecf314594771509ac13ff3be846
Fix typo in comment.
commit sha e3a06d7af6248a690940b5c5c3726806309261e1
Update gitignore file.
commit sha d31bbe260aa5bc2dc9da2aa2190ba93e5116baf1
Get rid rust-analyzer warning about shorthand struct initialization.
commit sha 1c4fd85f3e2ea0dcca77ed9e106e46eb36929b2a
Add a CI check that all crates in the workspace have a consistent version.
commit sha 86617c7dfc79d29731f9ee5844113a449fc8ba17
Make regex version_checker more robust.
commit sha 38e462d1d015d73dc8b08c325fb45bb6ca1f5125
Merge pull request #130 from michaelwoerister/better-version-checks Add a CI check that all crates in the workspace have a consistent version
commit sha cd3e70fb8491bfbdc35520edc7319b1e6d9db610
Extend FileSerializationSink to support in-memory storage and use this instead of ByteVecSink.
commit sha 77c6869fec65ae4cc083982c15da38712dfbc99f
Remove the MmapSerializationSink.
commit sha 603f0c9db01e28733ebe941065f7669543d9eb26
Remove the generic SerializationSink parameter from Profiler.
commit sha b4097fc1eaa57c7fe568cd0a4aea3b1f97a0bc31
Remove the generic SerializationSink parameter from StringTableBuilder.
commit sha b74043c2b2394abc9dd3bdcf9e97f0fbaa27bb6d
Remove the SerializationSink trait.
commit sha e5add84857479a472b82b3de36add29662a15eac
Rename FileSerializationSink to just SerializationSink, now that there is a single kind.
commit sha 4303a6d52d247f015f37ea655775ef4b2c2ce759
Add clarifying comment to BackingStorage::drain_bytes().
commit sha 40a26b642a62dd06c935af36dab4a81098dfe88f
Merge pull request #131 from michaelwoerister/remove_serialization_sink_trait Remove the SerializationSink trait
commit sha ce632523facabe74649f67bceb769876728e15aa
Turn serialization::BackingStorage into enum instead of a trait with two impls.
commit sha 1825a06d998175d63139005b0f2b95268a1de9bc
Implement paged serialization approach. This allows to store all data in a single file instead of three separate ones.
commit sha 440331eed5adbef2529b6825ed1248646e041054
stack-collapse -> stack_collapse in README Fix naming
commit sha 662d00db8a19a25e2d805042e5371131e852c3f2
Merge pull request #133 from tmandry/patch-1 stack-collapse -> stack_collapse in README
commit sha 410bcafbbc75336b3c4f3d7a4e03990cb1c51725
Update file header handling for paged data format.
commit sha 0d6725ed91e8c531645ea8fdbf5cf723bcef252d
Fix typo: profilng -> profiling
push time in 21 hours
Pull request review commentrust-lang/rust
Suggest adding missing braces in `const` block pattern
impl<'a> Parser<'a> { }) } else if self.eat_keyword(kw::Unsafe) { self.parse_block_expr(None, lo, BlockCheckMode::Unsafe(ast::UserProvided), attrs)- } else if self.check_inline_const() {- self.parse_const_expr(lo.to(self.token.span))+ } else if self.eat_keyword(kw::Const) {
The difference is that unsafe just modifies the block expression, whereas const needs to create the ExprKind::Const - but maybe it doesn't have to be too complicated shrug.
comment created time in a day
issue commentrust-lang/rust
ICE: const-generics-demangling.rs
Why is #[rustc_symbol_name] applied to an impl? impls don't have symbol names, the ICE is the same one for this:
#![feature(rustc_attrs)]
struct Foo;
#[rustc_symbol_name]
impl Foo {}
comment created time in a day
pull request commentrust-lang/rust
fix def collector for impl trait
@bors r+
comment created time in a day
push eventeddyb/measureme
commit sha ef25949adf2717e1176745ec9afbf6fe4bba9bd1
summarize: add "aggregate" sub-command for analyzing sets of profiles.
push time in 2 days
pull request commentrust-lang/rust
rustc_mir: track inlined callees in SourceScopeData.
I saw
eval_to_allocation_rawbeing slower for ctfe-stress-4.
Yeah, I was referring to everything other than ctfe-stress-4 (which, if it has MIR optimizations enabled, may necessarily get slowed down because MIR inlining is now more accurate).
comment created time in 2 days
pull request commentrust-lang/rust
WIP: Compile rustc crates with the initial-exec TLS model
If we're going to go that far, I would rather just see this mechanism fixed to make the TLS model depend on the top-level artifact(s)
Oh yeah I forgot I wanted that too (should be possible, based on my experiments an rlib crate is undecided between static and dynamic TLS until it's linked into a bin crate, or a dylib crate, respectively) and went down the rabbit hole of thinking about tracking which crates define #[thread_local] statics.
comment created time in 2 days
pull request commentrust-lang/rust
WIP: Compile rustc crates with the initial-exec TLS model
This may be silly, but, if we want to exactly track which crates are using TLS, so that we can list them out in the wrapper, we could:
- have an allow-by-default lint against using
#[thread_local](including fromthread_local!) - pass
-Fthread-localfrom thebootstrap/bin/rustc.rswrapper by default for all crates- specifically using "forbid" means
#[allow(thread_local)]wouldn't work so it couldn't be accidentally used
- specifically using "forbid" means
- for an explicit list of crates, we would omit
-Fthread-local- the subset of that which ends up linked into
librustc_driver-*.so, also get-Ztls-model=initial-exec
- the subset of that which ends up linked into
This could get confusing so we might want to make it an internal rustc::untracked_thread_local lint that has a custom message telling you to what list to add the crate etc.
comment created time in 2 days
Pull request review commentrust-lang/rust
WIP: Compile rustc crates with the initial-exec TLS model
fn main() { { cmd.arg("-C").arg("panic=abort"); }++ // Compile rustc crates with the more efficient initial-exec TLS model.+ // This doesn't work with `dlopen`, so we can't use it by default in+ // general, but we can use it for rustc's own internal libraries.+ if crate_name.map_or(false, |n| n.starts_with("rustc_") || n.starts_with("rustc-")) {+ cmd.arg("-Z").arg("tls-model=initial-exec");+ }
I wonder if we should also check that the path includes compiler/rustc_ because there's some stuff on crates.io that also starts with rustc_ or rustc- and it might not be strictly a rustc_driver dependency.
comment created time in 2 days
Pull request review commentalexcrichton/rustc-demangle
Elide the type when the const value is a placeholder `p`
impl<'a, 'b, 's> Printer<'a, 'b, 's> { } let ty_tag = parse!(self, next);++ if ty_tag == b'p' {+ // We don't encode the type if the value is a placeholder.+ self.out.write_str("_")?;+ return Ok(());+ }+ if !supported_const_generic_type(ty_tag) { invalid!(self); } - if self.eat(b'p') {- self.out.write_str("_")?;- } else {- match ty_tag {- // Unsigned integer types.- b'h' | b't' | b'm' | b'y' | b'o' | b'j' => self.print_const_uint()?,- // Signed integer types.- b'a' | b's' | b'l' | b'x' | b'n' | b'i' => self.print_const_int()?,- // Bool.- b'b' => self.print_const_bool()?,- // Char.- b'c' => self.print_const_char()?,-- // This branch ought to be unreachable.- _ => invalid!(self),- };- }+ match ty_tag {+ // Unsigned integer types.+ b'h' | b't' | b'm' | b'y' | b'o' | b'j' => self.print_const_uint()?,+ // Signed integer types.+ b'a' | b's' | b'l' | b'x' | b'n' | b'i' => self.print_const_int()?,+ // Bool.+ b'b' => self.print_const_bool()?,+ // Char.+ b'c' => self.print_const_char()?,++ // This branch ought to be unreachable.+ _ => invalid!(self),+ };
This can all be simplified by removing supported_const_generic_type.
I had some ideas for simplifying all of this code by removing the skip_ vs print_ split, given how much cleaner that made the C port, so I wouldn't worry about duplication.
comment created time in 2 days
Pull request review commentalexcrichton/rustc-demangle
Add support for `min_const_generics` constants
impl<'a, 'b, 's> Printer<'a, 'b, 's> { } v.fmt(self.out) }++ fn print_const_int(&mut self) -> fmt::Result {+ if self.eat(b'n') {+ self.out.write_str("-")?;+ }++ self.print_const_uint()+ }++ fn print_const_bool(&mut self) -> fmt::Result {+ match parse!(self, hex_nibbles).as_bytes() {+ b"0" => self.out.write_str("false"),+ b"1" => self.out.write_str("true"),+ _ => invalid!(self),+ }+ }++ fn print_const_char(&mut self) -> fmt::Result {+ let hex = parse!(self, hex_nibbles);++ // Valid `char`s fit in `u32`.+ if hex.len() > 8 {+ invalid!(self);+ }++ let mut v = 0;+ for c in hex.chars() {+ v = (v << 4) | (c.to_digit(16).unwrap() as u32);+ }+ if let Some(c) = char::from_u32(v) {+ write!(self.out, "'{}'", c)
This should use "{:?}" so that you get e.g. '\n' instead of literally a newline in the output etc.
comment created time in 2 days
pull request commentrust-lang/rust
rustc_mir: track inlined callees in SourceScopeData.
Does ctfe-stress-4 enable MIR inlining? Because in that case, that might make some sense.
The slight slowdowns don't reflect in the self-profile data, so I don't know where they're coming from.
But I think we can finally land this. cc @rust-lang/wg-mir-opt for a review of the MIR side and @nagisa for the LLVM parts.
comment created time in 2 days
pull request commentrust-lang/rust
rustc_mir: track inlined callees in SourceScopeData.
Given what I'm hearing about scopes in promoteds, this should be better now: @bors try @rust-timer queue
comment created time in 3 days
push eventeddyb/rust
commit sha 9b21c50335887fe9ecbd44d5a3efa105feae0a6d
rustc_mir: create the Integrator as soon as possible in MIR inlining.
commit sha aff4d3e659872ec1fbf469e91575a9a711ce4705
rustc_mir: run the MIR inlining Integrator on the whole callee body at once.
push time in 3 days
push eventeddyb/rust
commit sha 389f7cf7d6c333b490e208bcbda3406b9e0ef437
Rollup merge of #76745 - workingjubilee:move-wrapping-tests, r=matklad Move Wrapping<T> ui tests into library Part of #76268 r? @matklad
commit sha ccc020ab42b4209940b821ba4fd0e1240d3f7561
Rollup merge of #77182 - GuillaumeGomez:missing-examples-fd-traits, r=pickfire Add missing examples for Fd traits Not sure what happened here... This is a reopening of #77142 r? @Dylan-DPC
commit sha 65228686649c68f491d3b763e9dde52c23fea9d7
Rollup merge of #77251 - dtolnay:drop, r=Aaron1011 Bypass const_item_mutation if const's type has Drop impl Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation. ```rust struct Log { msg: &'static str } const LOG: Log = Log { msg: "" }; impl Drop for Log { fn drop(&mut self) { println!("{}", self.msg); } } LOG.msg = "wow"; // prints "wow" ``` r? @Aaron1011
commit sha 01ca8299d48df39a1567ec39f9768d8fcb69ce7f
Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio, r=dtolnay Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing. This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154, this should make output a little bit more efficient.
commit sha 23408de992598d89bf6ed697b4b86bbefc0f2df0
Rollup merge of #77421 - petrochenkov:globtravel, r=nagisa Revert "resolve: Avoid "self-confirming" import resolutions in one more case" And remove the assert that https://github.com/rust-lang/rust/pull/70236 tried to avoid instead. Closes https://github.com/rust-lang/rust/issues/74556.
commit sha eff63980142872227dcd66bf429f7337b1b68c31
Rollup merge of #77452 - Mark-Simulacrum:fix-symbol-v0, r=eddyb Permit ty::Bool in const generics for v0 mangling This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway). Fixes #76365 (well, it will, but seems fine to close as soon as we have support) r? @eddyb (for mangling) but I'm okay with some other reviewer too :)
commit sha 6ebad43c255e63ac0734646fe817de5780d76b45
Auto merge of #77470 - jonas-schievink:rollup-9a2hulp, r=jonas-schievink Rollup of 8 pull requests Successful merges: - #75377 (Fix Debug implementations of some of the HashMap and BTreeMap iterator types) - #76107 (Write manifest for MAJOR.MINOR channel to enable rustup convenience) - #76745 (Move Wrapping<T> ui tests into library) - #77182 (Add missing examples for Fd traits) - #77251 (Bypass const_item_mutation if const's type has Drop impl) - #77264 (Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. ) - #77421 (Revert "resolve: Avoid "self-confirming" import resolutions in one more case") - #77452 (Permit ty::Bool in const generics for v0 mangling) Failed merges: r? `@ghost`
commit sha d71d13e82d5a7cb3037a70d2ac18453db6dacca7
BTreeMap: refactoring around edges, missed spots
commit sha 21fb9dfa8d49d6aa3e74dfcc7032badcd6f51b91
Use old error when there's partial resolution The new error was confusing when there was partial resolution (something like `std::io::nonexistent`); the old one is better for those cases.
commit sha d1d2184db407dbdc0a0872c9efb4ff58457e1c9a
SsoHashSet/Map - genericiy over Q removed Due to performance regression, see SsoHashMap comment.
commit sha 8c54cf67c1bdae93ecef9791dc07c0982bb76041
Auto merge of #77451 - Mark-Simulacrum:bump-version, r=pietroalbini Bump version to 1.49.0 r? `@pietroalbini`
commit sha c47caeaaa9011fa4dd56d7e7b0ef341a0419b378
Macro-expand test to cover all possible lanes
commit sha aa9b718cf0d4157a81c5dcc8d59f2c4ed96b801e
Improve error messages
commit sha 6f56fbdc1c58992a9db630f5cd2ba9882d32e84b
Auto merge of #77347 - jyn514:dox, r=Amanieu Remove --cfg dox from rustdoc.rs This was added in https://github.com/rust-lang/rust/pull/53076 because several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`). I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think this is now safe to remove. r? `@Mark-Simulacrum` cc `@QuietMisdreavus` :)
commit sha e27ef130c1d1cc7d8c3779a4e66e413a7a943ad4
grammar nit
commit sha e6027a42e109fef10f4fc27ebede50d1b3d203f0
Add `unclosed_html_tags` lint
commit sha 5fcbf4668ecab0ff798ea076757e27760c90aff5
Add doc for invalid_html_tag lint
commit sha bc6ec6fe36c5c902da900fea67cba30fad4b0b6b
Add test for unclosed_html_tag lint
commit sha 6271a0a46dedd5eaf3eb26afb6ae536939496cd7
Improve invalid_html_tags lint span
commit sha f9a65afb27e0093b56053f810952efcba3e718e5
Make invalid_html_tags lint only run on nightly and being allowed by default
push time in 3 days
pull request commentrust-lang/rust
r? @pnkfelix (as per #72029 and #74971)
comment created time in 3 days
Pull request review commentrust-lang/rust
use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKi use rustc_middle::ty::Ty; use rustc_span::Span; use rustc_trait_selection::traits;+use std::mem; pub(super) struct GatherLocalsVisitor<'a, 'tcx> { fcx: &'a FnCtxt<'a, 'tcx>, parent_id: hir::HirId,+ // params are special cases of pats, but we want to handle them as+ // *distinct* cases. so track when we are hitting a pat *within* an fn+ // param.
params -> parameters, pat -> pattern
comment created time in 3 days
pull request commentrust-lang/rust
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name
@rfcbot reviewed
Doing it through the bot so I can say this: I disagree with doing anything here other than forcing distros' hand to adapt to something like https://github.com/rust-lang/compiler-team/issues/350#issuecomment-698372654 which would even allow them to compile some problematic (for now? hopefully there's a transition path...) packages with "unstable rustc for version 1.45" as opposed to "stable rustc 1.45 + RUSTC_BOOTSTRAP".
The important thing is that they would have control, and have to choose to exert it, over what gets to even use "unstable rustc", instead of being able to take any random stable rustc and make it unstable.
comment created time in 3 days
Pull request review commentrust-lang/rust
Separate unsized fn params from unsized locals
impl<'a, 'tcx> Visitor<'tcx> for GatherLocalsVisitor<'a, 'tcx> { intravisit::walk_local(self, local); } + fn visit_param(&mut self, param: &'tcx hir::Param<'tcx>) {+ self.within_fn_param = true;+ intravisit::walk_param(self, param);+ self.within_fn_param = false;+ }+ // Add pattern bindings. fn visit_pat(&mut self, p: &'tcx hir::Pat<'tcx>) { if let PatKind::Binding(_, _, ident, _) = p.kind { let var_ty = self.assign(p.span, p.hir_id, None); - if !self.fcx.tcx.features().unsized_locals {- self.fcx.require_type_is_sized(var_ty, p.span, traits::VariableType(p.hir_id));+ if self.within_fn_param {+ if !self.fcx.tcx.features().unsized_fn_params {+ self.fcx.require_type_is_sized(var_ty, p.span, traits::SizedArgumentType(None));+ }+ } else {+ if !self.fcx.tcx.features().unsized_locals {+ self.fcx.require_type_is_sized(var_ty, p.span, traits::VariableType(p.hir_id));+ } }
(summarizing my discussion with @spastorino on Zulip)
I think a bigger issue than special-casing the shape of the pattern, is that within_fn_param applies recursively to every nested pattern in a fn parameter, instead of to the parameter pattern itself.
So my suggestion is to replace it with a "shallow" version (bikeshed name: outermost_fn_param_pat) that visit_pat temporarily sets back to false around its walk_pat call, so that the #![feature(unsized_fn_params)] path is only taken for fn parameters themselves, not any other patterns nested in them.
comment created time in 3 days
Pull request review commentrust-lang/rust
Do not ICE with TraitPredicates containing [type error]
impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> { &predicate.subst(tcx, substs), &mut obligations, );- obligations.push(Obligation {- cause: cause.clone(),- recursion_depth,- param_env,- predicate,- });+ if predicate.references_error() {
Couldn't this check be done here: https://github.com/rust-lang/rust/blob/a85e94927622665a9e9022de0d33a890a2e32d43/compiler/rustc_trait_selection/src/traits/codegen/mod.rs#L123-L125
It's not obvious that there's any need to prevent errors from propagating in impl_or_trait_obligations, whereas turning an ICE into a delay_span_bug when .references_error(), in the snippet I linked, seems more natural.
But I don't care too strongly about this I don't think.
comment created time in 4 days
pull request commentrust-lang/rust
I have nothing against this change, FWIW.
comment created time in 5 days
Pull request review commentrust-lang/rust
CloneTypeFoldableAndLiftImpls! { // FIXME(eddyb) replace all the uses of `Option::map` with `?`. impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>> Lift<'tcx> for (A, B) { type Lifted = (A::Lifted, B::Lifted);- fn lift_to_tcx(&self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {- tcx.lift(&self.0).and_then(|a| tcx.lift(&self.1).map(|b| (a, b)))+ fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {+ let (a, b) = self;+ tcx.lift(a).and_then(|a| tcx.lift(b).map(|b| (a, b))) } } impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>, C: Lift<'tcx>> Lift<'tcx> for (A, B, C) { type Lifted = (A::Lifted, B::Lifted, C::Lifted);- fn lift_to_tcx(&self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {- tcx.lift(&self.0)- .and_then(|a| tcx.lift(&self.1).and_then(|b| tcx.lift(&self.2).map(|c| (a, b, c))))+ fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {+ let (a, b, c) = self;+ tcx.lift(a).and_then(|a| tcx.lift(b).and_then(|b| tcx.lift(c).map(|c| (a, b, c))))
If you're going to rewrite these, you can use ? nowadays.
E.g. Some((tcx.lift(a)?, tcx.lift(b)?, tcx.lift(c)?))
comment created time in 5 days
Pull request review commentrust-lang/rust
impl<'cx, 'tcx> dataflow::ResultsVisitor<'cx, 'tcx> for MirBorrowckCtxt<'cx, 'tc // "Lift" into the tcx -- once regions are erased, this type should be in the // global arenas; this "lift" operation basically just asserts that is true, but // that is useful later.- tcx.lift(&drop_place_ty).unwrap();+ tcx.lift(drop_place_ty).unwrap();
Yeah, I don't know what this did but it should be unnecessary. cc @nikomatsakis
comment created time in 5 days
pull request commentrust-lang/rust
Fix control flow check for breaking with diverging values
r? @nikomatsakis
comment created time in 5 days
pull request commentrust-lang/rust
normalize substs while inlining
@bors r+
comment created time in 5 days
pull request commentrust-lang/rust
fix def collector for impl trait
@bors r+
comment created time in 5 days
pull request commentrust-lang/rust
mangling: mangle impl params w/ v0 scheme
r=me though I'm not sure what's wrong with CI
comment created time in 9 days
issue commentjlgreathouse/AMD_IBS_Toolkit
Zen workaround missing for Zen 2 (which is also affected by SpecLockMap).
because IBS Op sampling only samples fully retired ops
Sadly it does seem to affect the "retired instructions" counter, so I guess it's not as "fully" retired as what IBS sees.
In any case, thanks for taking the time to respond! (I believe this might be the first time we heard back from anyone at AMD regarding the whole SpecLockMap saga, at all - then again, I don't think there was any attempt at grabbing anyone's attention, so no surprises there, heh)
And you can tell I'm also bad with notifications lately, didn't notice your reply until now.
comment created time in 9 days
issue commentrust-lang/rust
Implementation detail exposed in short backtrace (RUST_BACKTRACE=1)
This would go away if lang_start would be generic over main's type as F: FnOnce() -> R instead of taking a fn pointer, right? If you use -Z symbol-mangling-version=v0, you can see that the "inlined sometimes" call_once is <fn() as core::ops::function::FnOnce<()>>::call_once, i.e. the shim for calling a fn pointer via FnOnce.
One nice thing would that is we could theoretically allow varying not just main's return type, but also argument counts/types (which frankly I don't know why it hasn't come up before?).
comment created time in 15 days
issue commentrust-lang/rust
@marmeladema It's pretty much all in rustc_middle::ty::layout. Wherever field offsets are computed (univariant_uninterned), you can, for example, add the final alignment to all of the field offsets - this will increase the size of the whole type but keep all fields correctly aligned (and it's slightly simpler than changing field order, which has to be done similarly to how we sort fields by alignment).
You should be able to PM if you have more questions.
If you rely on the same flag to be passed across all the crates, or if you record what the choices were when a certain crate was contained (you could look at how -Z symbol-mangling-version is handled), you should be able to avoid problems with cross-crate consistency, which as per https://github.com/rust-lang/rust/issues/77316#issuecomment-701367977 was my main worry.
comment created time in 16 days
pull request commentrust-lang/rust
Don't run `resolve_vars_if_possible` in `normalize_erasing_regions`
I know what it's for (normalize may create inference variables), I'm just surprised it doesn't seem to be needed.
comment created time in 17 days
pull request commentrust-lang/rust
Let backends access span information
@bors r+
comment created time in 17 days
pull request commentrust-lang/rust
Force posix-style quoting on lld, independent of host platform
@bors r+
comment created time in 19 days
pull request commentrust-lang/rust
fix def collector for impl trait
@bors r+
comment created time in 19 days
Pull request review commentrust-lang/rust
Support signed integers and `char` in v0 mangling
impl Printer<'tcx> for SymbolMangler<'tcx> { } let start = self.out.len(); - match ct.ty.kind() {- ty::Uint(_) => {}- ty::Bool => {}+ let mut neg = false;+ let val = match ct.ty.kind() {+ ty::Uint(_) | ty::Bool | ty::Char => {+ ct.try_eval_bits(self.tcx, ty::ParamEnv::reveal_all(), ct.ty)+ }+ ty::Int(_) => {+ neg = true;+ ct.val
neg = true doesn't seem right when the value could be positive.
comment created time in 19 days
Pull request review commentrust-lang/rust
fix def collector for impl trait
impl<'a, 'hir> intravisit::Visitor<'hir> for HirIdValidator<'a, 'hir> { // we are currently in. So for those it's correct that they have a // different owner. }++ fn visit_generic_param(&mut self, param: &'hir hir::GenericParam<'hir>) {+ if let hir::GenericParamKind::Type {+ synthetic: Some(hir::SyntheticTyParamKind::ImplTrait),+ ..+ } = param.kind+ {+ // Do nothing because bodging is fun.
This needs a comment like visit_impl_item_ref, explaining that synthetic generics from impl Trait are HIR ID owners.
comment created time in 19 days
Pull request review commentrust-lang/rust
fix def collector for impl trait
impl Generics<'hir> { #[derive(HashStable_Generic)] pub enum SyntheticTyParamKind { ImplTrait,+ // Created by the `#[rustc_synthetic]` attribute.+ Rustc,
I'd call this RustcSyntheticAttr if you want to include Rustc in the name.
comment created time in 19 days
pull request commentrust-lang/rust
fix def collector for impl trait
@bors rollup=never (this is turning into something that may have sharp edge cases)
comment created time in 19 days
Pull request review commentrust-lang/rust
fix def collector for impl trait
+// run-pass+#![allow(unused_must_use)]+fn bug<T>() -> impl Iterator<Item = [(); { |x: u32| { x }; 4 }]> {
We're running into issues which suggest we also want examples where the impl Trait is in argument position.
(As that lowers to a generic parameter, which currently isn't a HIR owner)
comment created time in 19 days
pull request commentrust-lang/rust
fix def collector for impl trait
@bors r+ Thanks! (looks like this was an oversight)
comment created time in 19 days
issue commentbevyengine/bevy
Create and use StableTypeId instead of TypeId
Could building the "host" as an example in the bevy repo and the "dynamic plugin" as a separate cargo project that references the bevy repo cause the inconsistencies I saw?
That could cause two incompatible builds of bevy, you should check target/{debug,release}/deps/libbevy-*.rlib in both cases - if they have different hashes in the filenames, you are already introducing UB (Rust doesn't guarantee the ABI is the same, though we sadly don't do as much as we could to make it break much earlier).
But even then, two recompiles of the plugin shouldn't result in different TypeIds of type defined in the plugin itself.
comment created time in 19 days
issue commentgodot-rust/godot-rust
Change type_tag implementation to consider the possibility of a change in the layout of TypeId
Ah, I see, found it: https://github.com/godot-rust/godot-rust/blob/836fa993c875883702fbca4f3bc8347da4146bea/gdnative-core/src/nativescript/type_tag.rs#L73-L83
Yeah, you shouldn't rely on this. Consider amortizing the cost of using the boxed version instead (and, really, you can replace your Vec with an IndexSet<TypeId> and use even 32-bit integers, or smaller, instead of usize).
comment created time in 19 days
issue commentgodot-rust/godot-rust
Change type_tag implementation to consider the possibility of a change in the layout of TypeId
It's not usize, though? It's currently u64, are you sure the code in question compiles on 32-bit targets?
You can write [u8; size_of::<TypeId>()], but ideally you would rely on Eq and/or Hash.
comment created time in 19 days
issue commentbevyengine/bevy
Create and use StableTypeId instead of TypeId
If you are rebuilding the same Cargo project to obtain a newer build of the plugin, and this is a feature meant primarily for development uses, please use TypeId. If it breaks, that's great, because it means you're doing something wrong all of a sudden.
It's a very weak litmus test for basic things like "did I upgrade my Rust version and forgot to recompile the host binary" (if you're not linking bevy as a dylib, you will get duplication of everything between the host and the plugin, so things will appear to work even when they shouldn't - and I guess even if you do have a common dylib it will also probably succeed dynamic loading even if it's an incompatible version).
At the very least, if you move to something like "language-agnostic ComponentId", consider checking, on plugin loading, that things like TypeId::of::<bevy::SomeType>() agree between the host and the plugin. If they don't, do not run the plugin.
This is the least you can do to make sure you're not accidentally loading incompatible code.
comment created time in 19 days
pull request commentrust-lang/rust
Widen TypeId from 64 bits to 128.
the fallback (hash comparison) will be known-length which will be faster than comparing strings.
But any fixed length of hash is a mere probabilistic improvement, but not a soundness fix.
The reason we were even talking about strings is because they can encode enough information to be sound.
comment created time in 19 days
pull request commentrust-lang/rust
normalize substs while inlining
@bors r+ Thanks!
comment created time in 19 days
pull request commentrust-lang/reference
Document expression order for tuple expressions.
Why document any one thing in particular? The order is universally "postorder" (on the AST), i.e. "more nested" expressions first (effectively mandated by "expressions depend on the result of their subexpressions"), and between siblings it's specifically left-to-right (outside of perhaps assignments' LHS? I forget how we resolved that one).
Can't we specify it in one place? Doing it on a case-by-case basis seems inefficient and would suggest the order isn't uniformly defined, whereas it is (otherwise e.g. the borrow-checker couldn't possibly work).
cc @rust-lang/lang
comment created time in 20 days
pull request commentrust-lang/rust
updated p! macro to accept literals
@bors r+
comment created time in 20 days
pull request commentrust-lang/rust
Permit ty::Bool in const generics for v0 mangling
@bors r+ Btw do you have a matching rustc-demangle PR?
comment created time in 21 days
issue commentoschwald/maxminddb-rust
Can't build with panic = "abort"
It shouldn't impact anyone, you should avoid specifying crate_type in general, looks like it was left over from pre-Rust-1.0 days.
We should've deprecated dylib a long time ago, and staticlib is only useful if you're building a standalone C library (with a C API, which you don't have, so it does nothing for you).
comment created time in 21 days
issue commentrust-lang/cargo
indicate in cargo build whether incremental is in use
I've just spent my day telling different people about CARGO_INCREMENTAL=1 (and the .cargo/config.toml incremental = true, which is probably a better semi-permanent solution), and none of them were aware that release mode had it disabled.
So I think it would be useful to say incremental or non-incremental so that there's at least a hint.
comment created time in 21 days
Pull request review commentrust-lang/rust
Returns values up to 2*usize by value
where _ => return, } - let max_by_val_size =- if is_ret { call::max_ret_by_val(cx) } else { Pointer.size(cx) };+ // Return structures up to 2 pointers in size by value, matching `ScalarPair`. LLVM+ // will usually return these in 2 registers, which is more efficient than by-ref.+ let max_by_val_size = if is_ret { Pointer.size(cx) * 2 } else { Pointer.size(cx) };
I wonder if it makes sense to limit this to returns, but also whether 3 might work better than 2 as the multiplier.
But I guess there's a risk it might get downgraded from registers... I really wish LLVM modeled ABIs more precisely so we can control that.
comment created time in 22 days
Pull request review commentrust-lang/rust
Returns values up to 2*usize by value
impl<'a, Ty> FnAbi<'a, Ty> { Ok(()) } }--/// Returns the maximum size of return values to be passed by value in the Rust ABI.-///-/// Return values beyond this size will use an implicit out-pointer instead.-pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {- match spec.target_spec().arch.as_str() {- // System-V will pass return values up to 128 bits in RAX/RDX.- "x86_64" => Size::from_bits(128),
I was hoping removing this string comparison would help perf but I guess not?
comment created time in 22 days
Pull request review commentrust-lang/rust
Return values up to 128 bits in registers
impl<'a, Ty> FnAbi<'a, Ty> { Ok(()) } }++/// Returns the maximum size of return values to be passed by value in the Rust ABI.+///+/// Return values beyond this size will use an implicit out-pointer instead.+pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {+ match spec.target_spec().arch.as_str() {+ // System-V will pass return values up to 128 bits in RAX/RDX.+ "x86_64" => Size::from_bits(128),++ _ => spec.data_layout().pointer_size,+ }+}
That is, we already do 2 * pointer_size on all architectures, just not for arbitrary data, only pairs of scalars.
comment created time in 22 days
Pull request review commentrust-lang/rust
Improve std::sys::windows::compat
pub fn lookup(module: &str, symbol: &str) -> Option<usize> { } } -pub fn store_func(ptr: &AtomicUsize, module: &str, symbol: &str, fallback: usize) -> usize {- let value = lookup(module, symbol).unwrap_or(fallback);- ptr.store(value, Ordering::SeqCst);- value-}- macro_rules! compat_fn {- ($module:ident: $(+ ($module:literal: $( $(#[$meta:meta])*- pub fn $symbol:ident($($argname:ident: $argtype:ty),*)- -> $rettype:ty {- $($body:expr);*- }+ pub fn $symbol:ident($($argname:ident: $argtype:ty),*) -> $rettype:ty $body:block )*) => ($(- #[allow(unused_variables)] $(#[$meta])*- pub unsafe fn $symbol($($argname: $argtype),*) -> $rettype {+ pub mod $symbol {+ use super::*; use crate::sync::atomic::{AtomicUsize, Ordering}; use crate::mem;- type F = unsafe extern "system" fn($($argtype),*) -> $rettype; static PTR: AtomicUsize = AtomicUsize::new(0); + #[allow(unused_variables)]+ unsafe extern "system" fn fallback($($argname: $argtype),*) -> $rettype $body++ #[cold] fn load() -> usize {- crate::sys::compat::store_func(&PTR,- stringify!($module),- stringify!($symbol),- fallback as usize)+ // There is no locking here. It's okay if this is executed by multiple threads in+ // parallel. `lookup` will result in the same value, and it's okay if they overwrite+ // eachothers result as long as they do so atomically. We don't need any guarantees+ // about memory ordering, as this involves just a single atomic variable which is+ // not used to protect or order anything else.+ let addr = crate::sys::compat::lookup($module, stringify!($symbol))+ .unwrap_or(fallback as usize);+ PTR.store(addr, Ordering::Relaxed);+ addr }- unsafe extern "system" fn fallback($($argname: $argtype),*)- -> $rettype {- $($body);*++ fn addr() -> usize {+ match PTR.load(Ordering::Relaxed) {+ 0 => load(),+ addr => addr,+ } } - let addr = match PTR.load(Ordering::SeqCst) {- 0 => load(),- n => n,- };- mem::transmute::<usize, F>(addr)($($argname),*)+ #[allow(dead_code)]+ pub fn is_available() -> bool {+ addr() != fallback as usize
FWIW this looks fine to me now.
comment created time in 22 days
Pull request review commentrust-lang/rust
Return values up to 128 bits in registers
impl<'a, Ty> FnAbi<'a, Ty> { Ok(()) } }++/// Returns the maximum size of return values to be passed by value in the Rust ABI.+///+/// Return values beyond this size will use an implicit out-pointer instead.+pub fn max_ret_by_val<C: HasTargetSpec + HasDataLayout>(spec: &C) -> Size {+ match spec.target_spec().arch.as_str() {+ // System-V will pass return values up to 128 bits in RAX/RDX.+ "x86_64" => Size::from_bits(128),++ _ => spec.data_layout().pointer_size,+ }+}
Is there anything wrong with 2 * pointer_size? IIRC we already return pairs in two registers.
comment created time in 22 days
pull request commentrust-lang/rust
Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used.
You could use a thread-local Cell<bool>, that won't register a destructor, at least on cfg(target_thread_local) platforms.
comment created time in 22 days
issue commentmicrosoft/vscode
Task terminal truncates long/quick output.
IIUC, #38137 was fixed in version 1.49 but I can still reproduce my testcase above with:
Version: 1.49.1
Commit: 58bb7b2331731bf72587010e943852e13e6fd3cf
Date: 2020-09-16T23:23:33.049Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 5.4.59
So I'm pretty sure this is a different bug than #38137.
comment created time in 23 days
issue commentrust-lang/rfcs
Because Copy is a marker trait (no associated items), and its absence doesn't confer any additional powers (in general we try to avoid negative reasoning, I think - also see the previous comment where I show coherence is already future-proofed), I believe we can implement Copy on Range and feature-gate it.
While we still can't feature-gate individual impls without running into the complexity of all possible trait system interactions (and how it may behave across crates), we could "just" pretend Copy impls aren't there for types marked with #[must_clone], unless the feature-gate, e.g. #![feature(must_clone_copy_impls)] (bikeshed-ready name) is enabled.
There's one issue I see with this: if a dependency uses #![feature(must_clone_copy_impls)], definitions from it may result in ICEs when used/codegen'd in a downstream crate without the feature-gate. And I can think of two mitigations:
- avoid the feature in the standard library - this should avoid any cross-crate interactions for users which don't touch the feature-gate (or are on beta/stable), though it would limit dogfooding
- only hide the
#[must_clone]+Copyimpls inReveal::UserFacingmode (i.e. type-checking, borrow-checking, lints), notReveal::Allmode (everything else, including MIR optimizations, miri, codegen, etc.) - that way, MIR from dependencies should continue to codegen correctly, even in downstream crates without the feature-gate- this should make mitigation 1. irrelevant but we might still want to be careful about it
cc @nikomatsakis @matthewjasper Do you have any opinions on this strategy? I think if we can feature-gate Range<_>: Copy, we can land it much sooner, and go through the normal stabilization process.
comment created time in 23 days
PR closed rust-lang/rust
Background: (second half of) https://github.com/rust-lang/rfcs/issues/2848#issuecomment-697257283.
I'm opening this for two reasons:
- demonstrating the (relatively simple) implementation (though it could use specialized diagnostics)
- doing a crater run just in case simply having
Range<_>: Copybreaks something through e.g. inference
pr closed time in 23 days
pull request commentrust-lang/rust
[experiment] Add MustClone and impl Copy+MustClone on Range{,From,Inclusive}.
I'm closing this experiment PR, please continue discussion over at https://github.com/rust-lang/rfcs/issues/2848#issuecomment-701951599, to avoid fragmentation.
comment created time in 23 days
issue commentrust-lang/rfcs
If anyone is wondering, part of the reason adding Copy impls is backwards-compatible is, well, we future-proofed for it:
trait Trait {}
impl<T: Copy> Trait for T {}
impl Trait for std::ops::Range<usize> {}
That snippet produces (on playground) an error with this note:
upstream crates may add a new impl of trait
std::marker::Copyfor typestd::ops::Range<usize>in future versions
comment created time in 23 days
issue commentrust-lang/rfcs
Update on the experiment I was doing in https://github.com/rust-lang/rust/pull/77180: Range<_>: Copy appears to be backwards-compatible, like I was hoping it would be (see https://github.com/rust-lang/rust/pull/77180#issuecomment-701487663).
Quoting myself from that PR:
So we should be able to proceed here with an RFC or similar - though at the moment I don't have the bandwidth for anything like that, but if someone is interested in writing a
#[must_clone]/trait MustCloneRFC, feel free to show me drafts etc.
Importantly, I don't have a strong opinion on "attribute vs trait", and both implementation strategies should work (the attribute might be slightly easier even). I'd suggest looking for previous discussions of #[must_use] deficiencies (sadly I only have a vague memory of there being some discussion), or starting a t-lang thread on Zulip to discuss attribute vs trait.
comment created time in 23 days
pull request commentrust-lang/rust
[experiment] Add MustClone and impl Copy+MustClone on Range{,From,Inclusive}.
Thanks! At least it being a lint means it shouldn't impact any crates that depend on conrod_core / kiss3d_conrod.
And having that lint trip is a nice way to confirm that something is different.
So we should be able to proceed here with an RFC or similar - though at the moment I don't have the bandwidth for anything like that, but if someone is interested in writing a #[must_clone] / trait MustClone RFC, feel free to show me drafts etc.
comment created time in 23 days
issue commentrust-lang/rust
On Zulip @RalfJung pointed out that I didn't explain why you would want to make this deterministic (or why that's the main difficulty), so here's 3 reasons why this has to be deterministic:
- unsizing coercions mean that generic types need to have the same field order across instantiations, when the field types match (ignoring the field that would be unsized) - so we can reorder based on alignment, but not randomize differently each time
- layouts have to be the same for the same type across sibling crates (which do not know about eachother)
- introducing non-determinism into the query system is unsound at least for incremental recompilation (where you will get miscompiles, i.e. potentially UB in safe code, if you have things like order-dependency or outright RNG)
There's two ways to get deterministic per-type-definition "seeds":
- generate a random number when compiling the definition (and use that one value for shuffling the layout of every instance in any crate) - this is still troublesome with incremental, you would have to add it explicitly as an incremental input, in order to be sound, and it will cause a lot of invalidation
- use the
def_path_hash(which I mentioned in the previous comment), which is effectively theTypeIdhash corresponding to aDefId, and rely on its hash properties be pseudo-random (it should change with compiler releases and crate versions specified in theCargo.toml, so at least we should get some variety - though maybe not as much on nightly sadly)
You might probably also want a CLI flag to e.g. XOR in a fixed seed as well, even with the latter method, but it would have to be embedded in the type definition (so that it's correct cross-crate without requiring the same flag to passed in order to avoid miscompilation), so it's as much effort as both.
comment created time in 23 days
Pull request review commentrust-lang/rust
Fix control flow check for breaking with diverging values
impl<'a, 'tcx> FnCtxt<'a, 'tcx> { assert!(expr_opt.is_none() || self.tcx.sess.has_errors()); } - ctxt.may_break = true;+ // If we encountered a `break`, then (no surprise) it may be possible to break from the+ // loop... unless the value being returned from the loop diverges itself, e.g.+ // `break return 5` or `break loop {}`.+ ctxt.may_break |= !e_ty.is_never();
Like self.diverges (was looking for it).
comment created time in 24 days