Question: let fty = self.sanitize_type(place, fty); match self.field_ty(place, base, field, location) { Ok(ty) => { <ins> let ty = self.cx.normalize(ty, location); </ins> if let Err(terr) = self.cx.eq_types( ty, fty,

According to my CI this started 2020-04-16 (https://travis-) - : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reports a regression in (PR ), cc
Assigning as and removing .
assign
Oh dear, I was hoping crater will find all such issues (this is ). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays. I can repro by adding this line () to the test (and the PR fixing this should IMO add the line to ): The fix is likely trivial: add another normalization, like in Presumably, for field accesses, this time (weird that doesn't trigger the bug). <hr/I've brought it up before w/ (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming, so maybe there's no point.
I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase


Question: } fn visit_rvalue(&mut self, rvalue: &mut Rvalue<'tcx>, location: Location) { <del> if let Some(mtbl) = self.optimizations.and_stars.remove(&location) { </del> <ins> if self.optimizations.and_stars.remove(&location) { </ins> debug!("replacing `&*`: {:?}", rvalue); let new_place = match rvalue { Rvalue::Ref(_, _, place) => {

Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.


Question: } } (false, false) => { <del> t = Err(old_binding); </del> <ins> return Err(old_binding); </ins> } } <ins> } else { resolution.binding = Some(binding); </ins> } <del> } else { resolution.binding = Some(binding); }; </del> <ins> Ok(()) }) } fn ambiguity( &self, kind: AmbiguityKind, primary_binding: &'a NameBinding<'a>, secondary_binding: &'a NameBinding<'a>, ) -> &'a NameBinding<'a> { self.arenas.alloc_name_binding(NameBinding { ambiguity: Some((secondary_binding, kind)), ..primary_binding.clone() }) } // Use `f` to mutate the resolution of the name in the module. // If the resolution becomes a success, define it in the module's glob importers. fn update_resolution<T, F>(&mut self, module: Module<'a>, key: BindingKey, f: F) -> T where F: FnOnce(&mut Resolver<'a, 'tcx>, &mut NameResolution<'a>) -> T, { </ins> // Ensure that `resolution` isn't borrowed when defining in the module's glob importers, // during which the resolution might end up getting re-defined via a glob cycle. <del> let (binding, t) = match resolution.binding() { _ if old_binding.is_some() => return t, None => return t, Some(binding) => match old_binding { Some(old_binding) if ptr::eq(old_binding, binding) => return t, _ => (binding, t), }, </del> <ins> let (binding, t) = { let resolution = &mut *self.resolution(module, key).borrow_mut(); let old_binding = resolution.binding(); let t = f(self, resolution); match resolution.binding() { _ if old_binding.is_some() => return t, None => return t, Some(binding) => match old_binding { Some(old_binding) if ptr::eq(old_binding, binding) => return t, _ => (binding, t), }, } </ins> }; <del> drop(resolution); </del> // Define `binding` in `module`s glob importers. for import in module.glob_importers.borrow_mut().iter() { let mut ident = key.ident;

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.


Question: } }; let attrs = &item.attrs; <del> let sp = span_of_attrs(attrs); </del> <ins> let sp = span_of_attrs(attrs).unwrap_or(item.source.span()); </ins> let mut diag = cx.tcx.struct_span_lint_hir( lint::builtin::INTRA_DOC_LINK_RESOLUTION_FAILURE,

crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.


Question: nightly ) msg "overriding settings for $CFG_RELEASE_CHANNEL" CFG_ENABLE_LLVM_ASSERTIONS=1 <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> # FIXME(#37364) shouldn't have to disable this on windows-gnu case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; beta | stable) msg "overriding settings for $CFG_RELEASE_CHANNEL" <del> CFG_ENABLE_DEBUGINFO_LINES=1 </del> <ins> case "$CFG_BUILD" in *-pc-windows-gnu) ;; *) CFG_ENABLE_DEBUGINFO_LINES=1 ;; esac </ins> ;; dev) ;;

Failure happens in the crate: This probably has to do with how we're calling the "custom resume" function, unsure what's going on.
Duplicate of
Indeed!


Question: let trait_to_placeholder_args = impl_to_placeholder_args.rebase_onto(tcx, impl_m.container_id(tcx), trait_to_impl_args); <ins> let hybrid_preds = tcx .predicates_of(impl_m.container_id(tcx)) .instantiate_identity(tcx) .into_iter() .chain(tcx.predicates_of(trait_m.def_id).instantiate_own(tcx, trait_to_placeholder_args)) .map(|(clause, _)| clause); let param_env = ty::ParamEnv::new(tcx.mk_clauses_from_iter(hybrid_preds), Reveal::UserFacing); let param_env = traits::normalize_param_env_or_error( tcx, param_env, ObligationCause::misc(tcx.def_span(impl_m_def_id), impl_m_def_id), ); </ins> let infcx = &tcx.infer_ctxt().build(); let ocx = ObligationCtxt::new(infcx); // Normalize the impl signature with fresh variables for lifetime inference. <del> let norm_cause = ObligationCause::misc(return_span, impl_m_def_id); </del> <ins> let misc_cause = ObligationCause::misc(return_span, impl_m_def_id); </ins> let impl_sig = ocx.normalize( <del> &norm_cause, </del> <ins> &misc_cause, </ins> param_env, tcx.liberate_late_bound_regions( impl_m.def_id,

This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Check that we cannot have two sequence repetitions in a row. macro_rules! foo { ( $($a:expr)* $($b:tt)* ) => { }; //~ ERROR sequence repetition followed by another sequence ( $($a:tt)* $($b:tt)* ) => { }; //~ ERROR sequence repetition followed by another sequence } fn main() { } </ins>

In an example like we report the following error: This is part of the macro future-proofing code but it is an unnecessary limitation. For fragments that represent at most one token tree (, , , possibly others) there is no concern at all about being following by sequence repetition. This turns out to be a really big limitation in practice, since making macros that work over a generic sequence of token trees effectively allows for arbitrary parsing. cc
triage: P-medium
I'd be happy to mentor this, if I don't fix it first.
triage: P-medium
cc
I-ICE?
Curious why this was closed, looks like it's blocking lispy-rust.
It was fixed by ; do you still see this issue present in nightly?


Question: // #[rustc_main] let main_attr = ecx.attr_word(sym::rustc_main, sp); <ins> // #[no_coverage] let no_coverage_attr = ecx.attr_word(sym::no_coverage, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!-- <details<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .


Question: // #[rustc_main] let main_attr = ecx.attr_word(sym::rustc_main, sp); <ins> // #[no_coverage] let no_coverage_attr = ecx.attr_word(sym::no_coverage, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.


Question: (Some(Mode::ToolRustc), "rust_analyzer", None), (Some(Mode::ToolStd), "rust_analyzer", None), (Some(Mode::Codegen), "parallel_compiler", None), <ins> // NOTE: consider updating `check-cfg` entries in `std/Cargo.toml` too. // cfg(bootstrap) remove these once the bootstrap compiler supports // `lints.rust.unexpected_cfgs.check-cfg` </ins> (Some(Mode::Std), "stdarch_intel_sde", None), (Some(Mode::Std), "no_fp_fmt_parse", None), (Some(Mode::Std), "no_global_oom_handling", None),

With extra verbose flag (), one would see a lots of warnings about check-cfg when building -Zbuild-std. But it doesn't need to be that way. Can we doodfooding check-cfg flag to and to resolve them? Step to reproduce: I expected to see this happen: No warnings about " unexpected " Some are: label +F-check-cfg +-Zbuild-std cc


Question:
write!(w, "{}", impl_header)?; for implementor in local {  write!(w, "
")?;   write!(w, "
")?; if let Some(item) = implementor2item(&cache, implementor) { if let Some(l) = (Item { cx, item }).src_href() { write!(w, "
")?; write!(w, "[src]", l, "goto source code")?; write!(w, "
")?; } } write!(w, "")?;  // If there's already another implementor that has the same abbridged name, use the // full path, for example in `std::iter::ExactSizeIterator` let use_absolute = match implementor.impl_.for_ {

It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .


Question: // extensions <ins> pub fn get_args(&self) -> &[OsString] { &self.args } </ins> pub fn take_args(&mut self) -> Vec<OsString> { mem::replace(&mut self.args, Vec::new()) }

I'm having trouble linking a Rust program to a non-position-independent C library. When I manually remove the flag from the ld step that rustc runs, everything works correctly. I think that should remove the flag for me, but it doesn't. Here's what I think is going on: When I run It runs ld with the flag: But when I read the rustc code , it seems like the intention is that should only be passed to ld when . That is, if we're not compiling a position independent executable, then we should not pass the position independent executable flag to ld. I think what may be happening here is that somehow the defaults from are overriding the command line options I'm setting. This happens with stable and also the nightly I tried:
and are two distinct things. is also unrelated to the option. Interestingly, I do not remember us having an option to disable PIE; we should have one.
I did a bit of reading and here's what I figured out, please correct me if any of this is wrong. Linkers are new to me! Rust builds position independent executables by default on platforms that support it. These platforms have a relocation model of pic in their target config. The is what sets that linker option, except if it's disallowed by . The correct solution to this is to add a codegen flag, or something like that. Does this sound right?
Hi, I am having the same issue. I am trying to link against non-position-independent C library, build process ends without error but results returned by Rust bindings are different (and incorrect) than those returned from clean C implementation. In order to overcome that issue currently I am setting RUSTFLAGS="-C relocation-model=dynamic-no-pic -C linker=./linker" where linker is bash script that wraps cc and filter -pie flags:
I'm also having this problem. I assumed that passing when doing a build would suppress on the linker command line. (cc:
I'm still seeing this issue. Not sure if it's a regression or I'm doing something wrong. I have a "hello world" program in , and when I run , the resulting call to includes . I'm using nightly rust on Ubuntu: .
So, the problem here isn't with rust, but with the linker.


Question: // extensions <ins> pub fn get_args(&self) -> &[OsString] { &self.args } </ins> pub fn take_args(&mut self) -> Vec<OsString> { mem::replace(&mut self.args, Vec::new()) }

In Ubuntu 15.10 and later the default GCC toolchain installed has been compiled with which causes and to be passed to during code generation and to during linking. Now, the linking part is what is important here as rust on most platforms uses as the linker for most targets. So, though no PIC or PIE code may have been generated by , the linker will still try to link as with PIE in mind, breaking when trying to compile with and the like. To work around this will need to see that the linker has been compiled with PIE as the default and pass to the linker if using GCC or something similar for other linkers. Code to do this can be seen in for Tarpaulin though it is only meant for Linux in that state and can be improved greatly if in tree. EDIT: Don't know why Github isn't linking cross-project PRs correctly right now.
Can this issue be resolved by always passing , except when compiling with ?
Sadly, no. In testing I have seen that any build of GCC that was not built with rejects the option and fails to run. This is why in the PR that I linked the linker was queried to see if it was compiled with before tacking on .
So it's came out from the discussion on an issue related to this in tarpaulin that passing -no-pie before -shared (and maybe then -static if it exists for static linkages as well) resolves the issue. I'm going to test this tarpaulin side and I can report back but I feel it would be best if this could be solved rustc side as it can affect any user in a similar situation.


Question: find_testable_code(&dox, &mut tests, ErrorCodes::No); if check_missing_code == true && tests.found_tests == 0 { <del> let sp = span_of_attrs(&item.attrs).substitute_dummy(item.source.span()); </del> <ins> let sp = span_of_attrs(&item.attrs).unwrap_or(item.source.span()); </ins> let mut diag = cx.tcx.struct_span_lint_hir( lint::builtin::MISSING_DOC_CODE_EXAMPLES, hir_id,


Question: } } <del> debug!("enforce_member_constraint: final least choice = {:?}", least_choice); if least_choice != member_lower_bound { </del> <ins> // (#72087) Different `ty::Regions` can be known to be equal, for // example, we know that `'a` and `'static` are equal in a function // with a parameter of type `&'static &'a ()`. // // When we have two equal regions like this `expansion` will use // `lub_concrete_regions` to pick a canonical representative. The same // choice is needed here so that we don't end up in a cycle of // `expansion` changing the region one way and the code here changing // it back. let lub = self.lub_concrete_regions(least_choice, member_lower_bound); debug!( "enforce_member_constraint: final least choice = {:?}nlub = {:?}", least_choice, lub ); if lub != member_lower_bound { </ins> *var_values.value_mut(member_vid) = VarValue::Value(least_choice); true } else {

() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .


Question: const LEN: usize = 4; <del> struct SingleUnused(i32, [u8; LEN], String); //~^ ERROR: field `1` is never read </del> <ins> struct UnusedAtTheEnd(i32, f32, [u8; LEN], String, u8); //~^ ERROR:fields `1`, `2`, `3`, and `4` are never read //~| NOTE: fields in this struct //~| HELP: consider removing these fields struct UnusedJustOneField(i32); //~^ ERROR: field `0` is never read </ins> //~| NOTE: field in this struct <del> //~| HELP: consider changing the field to be of unit type </del> <ins> //~| HELP: consider removing this field </ins> <del> struct MultipleUnused(i32, f32, String, u8); //~^ ERROR: fields `0`, `1`, `2`, and `3` are never read </del> <ins> struct UnusedInTheMiddle(i32, f32, String, u8, u32); //~^ ERROR: fields `1`, `2`, and `4` are never read </ins> //~| NOTE: fields in this struct <del> //~| HELP: consider changing the fields to be of unit type </del> <ins> //~| HELP: consider changing the fields to be of unit type to suppress this warning while preserving the field numbering, or remove the fields </ins> struct GoodUnit(());

The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> error: prefix `world` is unknown --> $DIR/lex-bad-str-literal-as-char-4.rs:4:25 | LL |         println!('hello world'); |                         ^^^^^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-4.rs:4:30 | LL |         println!('hello world'); |                              ^^^ | help: if you meant to write a string literal, use double quotes | LL |         println!("hello world"); |                  ~           ~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0762`. </ins>

<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test to ensure we only report an error for the first issued loan that // conflicts with a new loan, as opposed to every issued loan.  This keeps us // down to O(n) errors (for n problem lines), instead of O(n^2) errors. fn main() { let mut x = 1; let mut addr; loop { match 1 { 1 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time 2 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time _ => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time } } } </ins>

Ran into this when running a fauly tt muncher with ~100 items. We can now compete with C++ in the compiler spew area as well! :-P
Ran into this while demonstrating why you need raw pointers to do a singly-linked-queue: 66 Borrow check errors in this test.


Question: } OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

The code around opt-levels indicates only nightly can use or . Non-nightly s should not even report those values as possible options.


Question: } OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

Added in these options are still unstable, this issue will track their progress to becoming stable!
Also note that is adding Cargo support, currently through and , but as we may want more human readable names.
I don't even think there is a single word that describes what does. As far as I know it was first introduced in clang and selected for its closeness to and connotations of compression, but this doesn't help at all when you need an immediately understandable token in
/ for and for ?
is right, "s" and "z" are not clear at all. I had no idea what "z" even did until I looked it up. it is the same as "s" but without loop vectorisation. According to it is intended to reduce size even further. I like the "size-1"/"size-2" idea.
We are potentially interested in this for Gecko's integration of Rust code, see [1]. We'd need to do more measurements to determine if the performance impact is acceptable though. [1]
thanks for the info! We haven't seen a lot of movement here in awhile and we've got support in Cargo/build scripts now, so I'd like to propose we stabilize this: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
IS this properly documented? That can come after we've approved for stability, right?
good point! I think we should definitely make sure it's documented at least in or the various man pages.
yes, that should come before the final PR itself lands though.
It seems like there was an open concern that these tokens (especially for Cargo) aren't very clear. Do we want to take a short at single-word tokens before stabilizing?
I'm not personally motivated to do so as this is such a niche feature it seems like it's not worth the effort, but others may feel differently.
I feel differently!


Question: } OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

If I change the patch to , and would that be acceptable? Or is it too late since Cargo has already merged and ? If so then we should probably stick with that but they should be properly documented since clearly very few people know what they mean.
I think we're definitely still able to change, we just might have to have a small period of time where we support everything to deprecate s/z
is there any particular reason that, for Cargo, we need more than just ? In practice, the main historical distinction between and was that was OSX-specific, and gave you "definitely, for realz optimize for size." As far as I can tell, Cargo really only needs a way for people to say "I want you to optimize for size, please" and having multiple different versions of "optimize for size" at the Cargo level seems likely to introduce more confusion than help. I propose that we add to Cargo, and not leak and . I think I feel the same way about but don't have as strong of an opinion there.
Sounds plausible to me! In that case sounds like there's work to do, so I'll cancel the FCP fcp cancel
proposal cancelled.
That's not what does, as far as I can tell. According to Clang's manual: Also see . By the way, there is also ! , which is: Sounds like it could be useful. I suggest for that.
I came here because I wasn't sure what -Oz did - now I know. I would like to point out that "size1" and "size2" is not much better, imho. Ok, so there's a size difference. But which one is supposed to be smaller? The bigger number, because it tries more agressively to make it smaller, or the smaller number, for intuitive reasons? I can see the parallel with O1, O2, O3 -increasing optimization for speed, and S1, S2, S3 -increasing optimization for size, but perhaps this should be made more explicit then? We can always keep "s", "o", and so on as shorthand aliases
Hello This seems to have gone to sleep. I mean, the name for it is important, but no discussion seems to be happening for like 9 months ‒ is it likely to move forward?


Question: } OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(

As for me, I'd rather have the feature stabilized (I'm often aiming at devices with chronic lack of storage space), no matter the actual values used. Or is it blocked on anything else beside choosing the right name?
Side note: the crash in only reproduces with -Os (probably an LLVM bug)
Since the lastest LLVM upgrade rustc / LLVM does more agressive ~inlining~ loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. . As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable. What can we do to move this forward. Can we at least stabilize "s" on rustc? Cargo already allows in the but requires a nightly toolchain. is this (opt-level) being discussed as part of the Cargo profile revamp?
I think those optimizations have baked long enough that it should be fine to stabilize now personally!


Question: use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_trait_selection::traits::{self, ObligationCauseCode}; <del> use std::fmt::Display; </del> impl<'a, 'tcx> FnCtxt<'a, 'tcx> { fn check_expr_eq_type(&self, expr: &'tcx hir::Expr<'tcx>, expected: Ty<'tcx>) { let ty = self.check_expr_with_hint(expr, expected);

I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.


Question: } } ast::TraitItemKind::Type(_, ref default) => { <del> // We use two if statements instead of something like match guards so that both // of these errors can be emitted if both cases apply. </del> <ins> // We use three if statements instead of something like match guards so that all // of these errors can be emitted if all cases apply. </ins> if default.is_some() { gate_feature_post!(&self, associated_type_defaults, ti.span, "associated type defaults are unstable");

clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24


Question: <del> use crate::t; </del> <ins> use crate::{t, VERSION}; </ins> use std::path::{Path, PathBuf}; use std::str::FromStr; use std::{

New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.


Question: "test/bench/shootout-meteor.rs", # BSD "test/bench/shootout-pidigits.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD <ins> "test/bench/shootout-reverse-complement.rs", # BSD </ins> "test/bench/shootout-threadring.rs", # BSD ]

See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial: OK OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () Cheers
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()


Question: // collect results based on the filter function if ident.name == lookup_ident.name && ns == namespace { <del> if filter_fn(name_binding.def()) { </del> <ins> let def = name_binding.def(); if filter_fn(def) { </ins> // create the path let mut segms = path_segments.clone(); if lookup_ident.span.rust_2018() {

For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.


Question: <ins> // run-pass // ignore-emscripten no subprocess support #![feature(set_stdio)] use std::fmt; use std::fmt::{Display, Formatter}; use std::io::set_panic; pub struct A; impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { panic!(); } } fn main() { set_panic(Some(Box::new(Vec::new()))); assert!(std::panic::catch_unwind(|| { eprintln!("{}", A); }) .is_err()); } </ins>

I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:


Question: fn main() -> () { let mut _0: ();                      // return place in scope 0 at $DIR/inline-generator.rs:8:11: 8:11 <del> let _1: std::ops::GeneratorState<<impl std::ops::Generator<bool> as std::ops::Generator<bool>>::Yield, <impl std::ops::Generator<bool> as std::ops::Generator<bool>>::Return>; // in scope 0 at $DIR/inline-generator.rs:9:9: 9:11 let mut _2: std::pin::Pin<&mut impl std::ops::Generator<bool>>; // in scope 0 at $DIR/inline-generator.rs:9:14: 9:32 let mut _3: &mut impl std::ops::Generator<bool>; // in scope 0 at $DIR/inline-generator.rs:9:23: 9:31 let mut _4: impl std::ops::Generator<bool>; // in scope 0 at $DIR/inline-generator.rs:9:28: 9:31 </del> <ins> let _1: std::ops::GeneratorState<i32, bool>; // in scope 0 at $DIR/inline-generator.rs:9:9: 9:11 let mut _2: std::pin::Pin<&mut [generator@$DIR/inline-generator.rs:15:5: 15:41]>; // in scope 0 at $DIR/inline-generator.rs:9:14: 9:32 let mut _3: &mut [generator@$DIR/inline-generator.rs:15:5: 15:41]; // in scope 0 at $DIR/inline-generator.rs:9:23: 9:31 let mut _4: [generator@$DIR/inline-generator.rs:15:5: 15:41]; // in scope 0 at $DIR/inline-generator.rs:9:28: 9:31 </ins> +     let mut _7: bool;                    // in scope 0 at $DIR/inline-generator.rs:9:14: 9:46 scope 1 { debug _r => _1;                  // in scope 1 at $DIR/inline-generator.rs:9:9: 9:11

Previously: Now: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc


Question: | = help: add #![feature(generic_associated_types)] to the crate attributes to enable <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:16:5 | LL |     type Pointer2<T>: Deref<Target = T> where T: Clone, U: Clone; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable </ins> error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:22:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:23:5 </ins> | LL |     type Pointer<usize> = Box<usize>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Question: <ins> fn part(_: u16) -> u32 { 1 } fn main() { for n in 100_000.. { //~^ ERROR: literal out of range for `u16` let _ = part(n); } } </ins>

An ICE is observable with this code: Changing to take a rather than makes the ICE go away.
Investigation shows that will trigger the ICE, while will not
Introduced in cc We can probably get away with doing an early return if and no other changes.


Question: <ins> error[E0726]: implicit elided lifetime not allowed here --> $DIR/wf-in-foreign-fn-decls-issue-80468.rs:13:16 | LL | impl Trait for Ref {} |                ^^^- help: indicate the anonymous lifetime: `<'_>` error[E0308]: mismatched types --> $DIR/wf-in-foreign-fn-decls-issue-80468.rs:16:21 | LL |     pub fn repro(_: Wrapper<Ref>); |                     ^^^^^^^^^^^^ lifetime mismatch | = note: expected trait `Trait` found trait `Trait` note: the anonymous lifetime #1 defined on the method body at 16:5... --> $DIR/wf-in-foreign-fn-decls-issue-80468.rs:16:5 | LL |     pub fn repro(_: Wrapper<Ref>); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Repro: As of current nightly: This is the unreachable line: The same crash reproduces back to 1.47.0. Older stable compilers do not crash:
Bisect: searched nightlies: from nightly-2020-07-10 to nightly-2020-08-27 regressed nightly: nightly-2020-07-22 searched commits: from to regressed commit: () Mentioning because appears the most relevant.
Assigning .


Question: } // walk type and init value <del> self.visit_ty(typ); if let Some(expr) = expr { self.visit_expr(expr); } </del> <ins> self.nest_tables(id, |v| { v.visit_ty(typ); if let Some(expr) = expr { v.visit_expr(expr); } }); </ins> } // FIXME tuple structs should generate tuple-specific data.

When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?


Question: } // walk type and init value <del> self.visit_ty(typ); if let Some(expr) = expr { self.visit_expr(expr); } </del> <ins> self.nest_tables(id, |v| { v.visit_ty(typ); if let Some(expr) = expr { v.visit_expr(expr); } }); </ins> } // FIXME tuple structs should generate tuple-specific data.

I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well


Question: LL - fn f4<X: ?Sized + T>(x1: Box<X>, x2: Box<X>, x3: Box<X>) { LL + fn f4<X: T>(x1: Box<X>, x2: Box<X>, x3: Box<X>) { | <ins> help: consider borrowing here | LL |     let y: &X = *x1; |            + </ins> error[E0277]: the size for values of type `X` cannot be known at compilation time --> $DIR/unsized6.rs:32:9

I tried compiling this code: which resulted in the following output of rustc: So the compiler says So I tried adding a borrow and recompiling the code: which resulted in: so the compiler says and so I'm stuck in a loop. The compiler can't decide whether I should borrow or not. As a newbie to Rust, this is very frustrating and the opposite of helpful, it just confuses me further. Please fix this indecisiveness :) :
For reference, what you likely want to do is one of the following which means they cannot be the type of a local binding. You can give a binding a slice type (), because that's morally equivalent to a pointer (with sizing info), which has a compile time determined size, as all borrows are .
Current output: After :


Question: <ins> #![deny(unused_must_use)] use std::{ops::Deref, pin::Pin}; #[must_use] struct MustUse; #[must_use] struct MustUsePtr<'a, T>(&'a T); impl<'a, T> Deref for MustUsePtr<'a, T> { type Target = T; fn deref(&self) -> &Self::Target { self.0 } } fn pin_ref() -> Pin<&'static ()> { Pin::new(&()) } fn pin_ref_mut() -> Pin<&'static mut ()> { Pin::new(unimplemented!()) } fn pin_must_use_ptr() -> Pin<MustUsePtr<'static, ()>> { Pin::new(MustUsePtr(&())) } fn pin_box() -> Pin<Box<()>> { Box::pin(()) } fn pin_box_must_use() -> Pin<Box<MustUse>> { Box::pin(MustUse) } fn main() { pin_ref(); pin_ref_mut(); pin_must_use_ptr(); //~ ERROR unused pinned `MustUsePtr` that must be used pin_box(); pin_box_must_use(); //~ ERROR unused pinned boxed `MustUse` that must be used } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Defining traits that contain methods that return such a type: The compiler should probably have warned me about not using the of the , consistent with the behaviour of async functions in Rust 1.67.0. This will also work without the need for traits but async traits is one of the most common use cases for such a type. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We looked at this as the wg-async triage meeting today. We agree this is a bug and that the behavior should be consistent with on and/or . This is also likely a good first issue for someone wanting to contribute to async.
Would you say this is also a good issue for a first-time contributor to Rust? I'm not super familiar with the language, but I want to contribute to open source compilers, so I'm hoping to potentially take on this task.
Can I take this ?
Either one of you ( or are welcome to work on this! If it's your first time contributing to Rust, it might take a while to ramp up on it, but I find the best way to do that is to just do it. If you decided to have a go at it, feel free to ask any questions you have either here or in . I tend to watch #wg-async closer than GitHub issues, so you'll probably get a more prompt reply there.
this issue wasn't claimed so you are free to claim and work on it if you still are interested. Kindly comment with to claim the issue.
claim
This is also a very special case of


Question: } else { // recent versions of gcc can be configured to generate position // independent executables by default. We have to pass -no-pie to <del> // explicitly turn that off. if sess.target.target.options.linker_is_gnu { </del> <ins> // explicitly turn that off. Not applicable to ld. if sess.target.target.options.linker_is_gnu && sess.linker_flavor() != LinkerFlavor::Ld { </ins> cmd.no_position_independent_executable(); } }

Updated to via rustup. I have a and additional which specify additional rustc arguments. Now if I run The build will succeed but then fail to run qemu because Instead, there's a file named in the directory where xargo was run from. To fix this I had to change the target json file with these options: I'm afraid this could subtly break my builds elsewhere, as the linker is, in fact, GNU ld. I believe this is related to the latest -pie/-no-pie patches which somehow interfere with custom cargo linker arguments specifications (where ends up landing instead of output file name).
Seems like is likely to be related?
That's my suspicion
hmm my change shouldn't have impacted when the -pie flag was sent, only the -no-pie flag. what version were you using before?
Could you please build with and post the output related to the link step (after the line)
triage: P-high Not assigning this to anyone immediately, since seems to be on it -- if you could take a shot at supplying that debug output it would be very helpful, thanks. =)
does that contain the info you needed?
It does look weird as I don't see any standalone in the command line.
Yes, that helps. I think this is what is happening: Even though you have set in your target file to produce position-independent-executables (pass the "-pie" flag), the code overrides this because it sees "-static" on the linker's command line and decides not to generate PIE. My PR made it pass "-no-pie" in this case, and fall back to removing -no-pie if the link fails For some reason this seems to be confusing ld instead of causing it to generate an error Can you confirm this by manually running: (same command line without -no-pie) to see if it works correctly, and also a ? I need to look more into ld to see if -no-pie is even necessary for it, I think maybe the default pie stuff might only be applicable with the gcc front-end. If so, I think the fix would be to change the code not to generate -no-pie if linking with ld.
nm, I think I was able to reproduce this. I don't see -no-pie documented for ld so I think that is the problem. I'll work on a fix.
Thanks, I will test this asap!
Works! Thank you!


Question: <ins> // Regression test for issue #124935 // Tests that we still emit an error after an item. fn main() { } ; //~ ERROR expected item, found `;` </ins>

Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.


Question: } } <ins> fn bound_from_single_component( &self, component: &Component<'tcx>, visited: &mut SsoHashSet<GenericArg<'tcx>>, ) -> VerifyBound<'tcx> { match *component { Component::Region(lt) => VerifyBound::OutlivedBy(lt), Component::Param(param_ty) => self.param_bound(param_ty), Component::Projection(projection_ty) => self.projection_bound(projection_ty, visited), Component::EscapingProjection(ref components) => { self.bound_from_components(components, visited) } Component::UnresolvedInferenceVariable(v) => { // ignore this, we presume it will yield an error // later, since if a type variable is not resolved by // this point it never will be self.tcx.sess.delay_span_bug( rustc_span::DUMMY_SP, &format!("unresolved inference variable in outlives: {:?}", v), ); // add a bound that never holds VerifyBound::AnyBound(vec![]) } } } </ins> /// Searches the environment for where-clauses like `G: 'a` where /// `G` is either some type parameter `T` or a projection like /// `T::Item`. Returns a vector of the `'a` bounds it can find.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.


Question: for (region_a, region_a_idx) in &regions { // Ignore `'static` lifetimes for the purpose of this lint: it's // because we know it outlives everything and so doesn't give meaningful <del> // clues if let ty::ReStatic = **region_a { </del> <ins> // clues. Also ignore `ReError`, to avoid knock-down errors. if let ty::ReStatic | ty::ReError(_) = **region_a { </ins> continue; } // For each region argument (e.g., `'a` in our example), check for a

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: <ins> // edition:2018 use std::{future::Future, marker::PhantomData}; fn spawn<T>(future: T) -> PhantomData<T::Output> where T: Future, { loop {} } #[derive(Debug)] struct IncomingServer {} impl IncomingServer { async fn connection_handler(handler: impl Sized) -> Result<Ok, std::io::Error> { //~^ ERROR expected type, found variant `Ok` [E0573] loop {} } async fn spawn(&self, request_handler: impl Sized) { async move { spawn(Self::connection_handler(&request_handler)); }; } } fn main() {} </ins>

The full repo is here: : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For what it's worth, I can reproduce this issue with version 1.63.0, but it doesn't happen with 1.64.0 nor with the latest stable version 1.66.0.
The ICE disappeared in nightly-2022-07-01, which contains the following merges: [x] : ICEs [x] : ICEs [x] : ICEs [x] : ICEs [ ] [x] : ICEs
Here is it minified, and standalone-ed:
Triage: This has been fixed on the latest nightly, as reported, and needs a test to close.
claim


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::fmt::Debug; const CONST_0: Debug+Sync = *(&0 as &(Debug+Sync)); //~^ ERROR `std::fmt::Debug + Sync + 'static: std::marker::Sized` is not satisfied //~| NOTE does not have a constant size known at compile-time //~| NOTE constant expressions must have a statically known size const CONST_FOO: str = *"foo"; //~^ ERROR `str: std::marker::Sized` is not satisfied //~| NOTE does not have a constant size known at compile-time //~| NOTE constant expressions must have a statically known size static STATIC_1: Debug+Sync = *(&1 as &(Debug+Sync)); //~^ ERROR `std::fmt::Debug + Sync + 'static: std::marker::Sized` is not satisfied //~| NOTE does not have a constant size known at compile-time //~| NOTE constant expressions must have a statically known size static STATIC_BAR: str = *"bar"; //~^ ERROR `str: std::marker::Sized` is not satisfied //~| NOTE does not have a constant size known at compile-time //~| NOTE constant expressions must have a statically known size fn main() { println!("{:?} {:?} {:?} {:?}", &CONST_0, &CONST_FOO, &STATIC_1, &STATIC_BAR); } </ins>

This looks unintentional, and has been broken in all cases, until a few releases ago, AFAICT. Should this be covered by WF rules? cc Unsized constants cause an ICE, in both old trans and MIR trans: Unsized statics appear to work, but only in old trans: I believe this is possible because a constant DST lvalue in old trans is merely the fat pointer. It seems useful to allow an unsized , but IMO it should require a sized RHS instead, i.e.: And, of course, this should all go through the RFC process, to figure out all the finer details.
Should it be ? I don't think A needs to be an lvalue.
It makes more sense for constants, but I gave the example with because that's the only one that works today (although by accident).
Hmm? I mean the static is desugared into a const. works today.
The idea being that a static and a const reference both give access to one lvalue.
No, has different semantics: it allows an somewhere within and is guaranteed not to be duplicated.
Hmm? Both of these gives me a "error: cannot borrow a constant which contains interior mutability, create a static instead". This is what I'd suspect as the lvalue from the promoted has nothing to do with being a or a .
Let me rewrite my desugaring to account for that, oops.
Oh and my confusion really just stemmed from forgetting about the constants referring to statics rule. [Kind of a funny rule when works, but this is an orthogonal issue.]
I think in the meantime unsized statics should probably error, perhaps dependent on a crater run, though I doubt there's many people relying on said bug. It's much easier to relax restrictions than tighten them.
Will prepare a patch to turn this into an error, hopefully nobody has been abusing it.


Question: let tcx = self.infcx.tcx; let generics = tcx.generics_of(self.mir_def_id); let param = generics.type_param(&param_ty, tcx); <del> let generics = tcx.hir().get_generics(self.mir_def_id).unwrap(); suggest_constraining_type_param( generics, &mut err, &param.name.as_str(), "Copy", tcx.sess.source_map(), span, ); </del> <ins> if let Some(generics) = tcx.hir().get_generics(self.mir_def_id) { suggest_constraining_type_param( generics, &mut err, &param.name.as_str(), "Copy", tcx.sess.source_map(), span, ); } </ins> } let span = if let Some(local) = place.as_local() { let decl = &self.body.local_decls[local];

I encounter an ICE: with rustc 1.41.0-nightly ( 2019-11-29) running on x8664-apple-darwin when compiling The same code does not ICE when using nightly-2019-11-27-x8664-apple-darwin Sorry, I haven't taken the time to make a minimal reproduction example.
Can you post the ICE message and backtrace?
Certainly! Although it is not the best stacktrace I have ever seen. Backtrace:
Backtrace:
modify labels: A-mir
I think I have a clue here: First the code: The problem seems to be a partial move of together with async together with a generic type (if we replace by for example, rust will complain as well and no ICE). If we remove the rust will complain: modify labels: +A-async-await -E-needs-mcve +E-needs-bisection
Regression in cc modify labels: -E-needs-bisection
triage: has PR. P-high, removing nomination.


Question: <ins> #![deny(suspicious_auto_trait_impls)] auto trait Trait<P> {} //~ ERROR auto traits cannot have generic parameters //~^ ERROR auto traits are experimental and possibly buggy impl<P> Trait<P> for () {} fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2022-02-02 found 9 bors merge commits in the specified range commit[0] 2022-01-31: Auto merge of - spastorino:fix-perf-overlap-mode2, r=nikomatsakis commit[1] 2022-01-31: Auto merge of - tmiasko:is-self-recursive, r=ecstatic-morse commit[2] 2022-02-01: Auto merge of - WaffleLapkin:rustcmustimplementoneofchecktarget, r=nagisa commit[3] 2022-02-01: Auto merge of - eddyb:diagbld-scalar-pair, r=jackh726 commit[4] 2022-02-01: Auto merge of - ehuss:rollup-9ecozo9, r=ehuss commit[5] 2022-02-01: Auto merge of - thomcc:chunky-splitz-says-no-checking, r=the8472 commit[6] 2022-02-01: Auto merge of - eholk:disable-drop-range-analysis, r=pnkfelix commit[7] 2022-02-01: Auto merge of - matthiaskrgr:rollup-f7dkn3p, r=matthiaskrgr commit[8] 2022-02-01: Auto merge of - yaahc:Termination-abstraction, r=Mark-Simulacrum ERROR: no CI builds available between and within last 167 days
Actually reduced
Might have been caused by
Ah yes, the assert was there ping :)


Question: } } <ins> fn async_block_with_borrow_named_lifetime<'a>(x: &'a u8) -> impl Future<Output = u8> + 'a { async move { await!(wake_and_yield_once()); *x } } </ins> fn async_nonmove_block(x: u8) -> impl Future<Output = u8> { async move { let future = async {

suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.


Question: } } <ins> fn async_block_with_borrow_named_lifetime<'a>(x: &'a u8) -> impl Future<Output = u8> + 'a { async move { await!(wake_and_yield_once()); *x } } </ins> fn async_nonmove_block(x: u8) -> impl Future<Output = u8> { async move { let future = async {

Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:


Question: err.multipart_suggestion_verbose(descr, suggestion, Applicability::MaybeIncorrect); err } <ins> Res::Def(DefKind::Variant, _) if expr.is_none() => { err.span_label(span, format!("not a {expected}")); let fields = &tcx.expect_variant_res(res).fields.raw; let span = qpath.span().shrink_to_hi().to(span.shrink_to_hi()); let (msg, sugg) = if fields.is_empty() { ("use the struct variant pattern syntax".to_string(), " {}".to_string()) } else { let msg = format!( "the struct variant's field{s} {are} being ignored", s = pluralize!(fields.len()), are = pluralize!("is", fields.len()) ); let fields = fields .iter() .map(|field| format!("{}: _", field.name.to_ident_string())) .collect::<Vec<_>>() .join(", "); let sugg = format!(" {{ {} }}", fields); (msg, sugg) }; err.span_suggestion_verbose( qpath.span().shrink_to_hi().to(span.shrink_to_hi()), msg, sugg, Applicability::HasPlaceholders, ); err } </ins> _ => err.with_span_label(span, format!("not a {expected}")), } .emit()

I wrote code that looked like this while not having my brain turned on 100%. Due to said brain not functioning, it took me a while to understand what rustc was trying to tell me with the message pointing to the pattern with the text . sure looked like a unit variant to me! What rustc was trying to tell me was that the definition of the variant was a struct variant ("found struct variant") and my pattern wasn't matching the definition ("this pattern you specified looks like it's trying to match a variant that is not a unit struct, unit variant or constant"). The change I needed to make was adding to my pattern, because I was trying to distinguish different variants from each other, not use pieces within the variants. Suggesting seems like a decent starting point to me, but there could definitely be cases I'm not considering here and I'm totally open to hearing that No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WEIRD this PR looks like it implements what I wish rustc did: but the test files in that PR say they're for and I'm getting
Aha ok this test shows that for tuple variants, rustc will suggest adding : and that test also shows that rustc isn't suggesting anything for struct variants!
Aha and it looks like adding struct fields was more complex so that's why it wasn't done?
claim


Question: LL - fn f3<X: ?Sized>(x1: Box<X>, x2: Box<X>, x3: Box<X>) { LL + fn f3<X>(x1: Box<X>, x2: Box<X>, x3: Box<X>) { | <ins> help: consider borrowing here | LL |     let y: &X = *x1; |            + </ins> error[E0277]: the size for values of type `X` cannot be known at compilation time --> $DIR/unsized6.rs:24:9


Question: if c.pgp { pgp::init(c.root); <ins> } else { warn("command "gpg" is not found"); warn("you have to install "gpg" from source " + " or package manager to get it to work correctly"); </ins> } c

cargo is relying on the to find rustc, but if one runs cargo with , cargo will error out with the unhelpful: cargo should detect this and return a proper error message for this. A proper workaround for this is to make sure that has an absolute path to the binaries set, as in: It needs to be absolute because cargo does a chdir to the build directory, which would break a relative path.
We have a function, that cargo can use to determine the path to itself, then use to launch the corresponding rustc.


Question: if c.pgp { pgp::init(c.root); <ins> } else { warn("command "gpg" is not found"); warn("you have to install "gpg" from source " + " or package manager to get it to work correctly"); </ins> } c

Instead of just saying the key can't be verified, explain why.
Yeah, it should also not fail! Missing gpg is a warning condition, not an error condition.


Question: <ins> error[E0425]: cannot find function `foo1` in crate `similar_unstable_method` --> $DIR/issue-109177.rs:7:30 | LL |     similar_unstable_method::foo1(); |                              ^^^^ help: a function with a similar name exists: `foo` | ::: $DIR/auxiliary/similar-unstable-method.rs:5:1 | LL | pub fn foo() {} | ------------ similarly named function `foo` defined here error[E0599]: no method named `foo1` found for struct `Foo` in the current scope --> $DIR/issue-109177.rs:11:9 | LL |     foo.foo1(); |         ^^^^ method not found in `Foo` error: aborting due to 2 previous errors Some errors have detailed explanations: E0425, E0599. For more information about an error, try `rustc --explain E0425`. </ins>

It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Question: n => { let m = cmp::min(n, self.steals); self.steals -= m; <del> self.cnt.fetch_add(n - m, atomics::SeqCst); </del> <ins> self.bump(n - m); </ins> } } assert!(self.steals >= 0); } <ins> self.steals += 1; </ins> match data { Data(t) => Ok(t), GoUp(up) => Err(Upgraded(up)),

PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.


Question: impl Foo for SignedBar { const BAR: i32 = -1; <del> //~^ ERROR E0326 </del> <ins> //~^ ERROR implemented const `BAR` has an incompatible type for trait //~| expected u32, //~| found i32 [E0326] </ins> } fn main() {}

The multi-line errors should be extended to include this testcase. missed this because the didn't go through . I tried but that didn't work either. If someone can point me to to where to catch it, I can probably fix this too. cc Code: Error: Change to:


Question: }; fn a_test() {} #[rustc_main] <ins> #[no_coverage] </ins> pub fn main() -> () { extern crate test; test::test_main_static(&[&a_test, &m_test, &z_test])

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!-- <details<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .


Question: }; fn a_test() {} #[rustc_main] <ins> #[no_coverage] </ins> pub fn main() -> () { extern crate test; test::test_main_static(&[&a_test, &m_test, &z_test])

However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.


Question: variant_index: VariantIdx, dest: PlaceTy<'tcx, M::PointerTag>, ) -> InterpResult<'tcx> { <del> let variant_scalar = Scalar::from_u32(variant_index.as_u32()).into(); </del> <ins> // Layout computation excludes uninhabited variants from consideration // therefore there's no way to represent those variants in the given layout. if dest.layout.for_variant(self, variant_index).abi.is_uninhabited() { throw_ub!(Unreachable); } </ins> match dest.layout.variants { layout::Variants::Single { index } => { <del> if index != variant_index { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> assert_eq!(index, variant_index); </ins> } layout::Variants::Multiple { discr_kind: layout::DiscriminantKind::Tag,

I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .


Question: /// expression of type `&'static str` which represents all of the literals /// concatenated left-to-right. /// <del> /// Integer and floating point literals are stringified in order to be </del> <ins> /// Integer and floating point literals are [stringified](core::stringify) in order to be </ins> /// concatenated. /// /// # Examples

I was sent here from the . Please advise if I am posting in the wrong area. format! macro documentation could be improved by changing one of the examples to be more obvious to new users. Change the example to Additionally, assert! could be used to demonstrate final string values: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Something like ? claim
I think the use of "val" certainly makes it more obvious than my suggestion to use "z". Your suggestion would also do it in one line... I guess the question is whether you would prefer to make it more obvious (readable) by splitting it into two lines. This is my first contribution to Rust in any form, so I'm happy to go with your suggestion.
Thanks all!


Question: add_lint_group!(sess, "rust_2018_idioms", BARE_TRAIT_OBJECT, <del> UNREACHABLE_PUB); </del> <ins> UNREACHABLE_PUB, UNNECESSARY_EXTERN_CRATE); </ins> // Guidelines for creating a future incompatibility lint: //

We need to add an epoch lint for It will lint , suggesting removal in root mods, and replacement with in non-root mods. This is blocked on the ability to elide extern crate in the first place.
It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards:
cc
I think the lint should be by default off in cases with , such as: This is because of the ergonomics problems with macros and the new macro import system, expressed here: It's bewildering for the migrating users if a lint tells them not to use the syntax, but then finding out that many of the macros out there have downright bad ergonomics with the import syntax. (For clarification: I think this is an undesirable state of affairs, and we should be linting against all , but if we do that, the ergonomics problem with the macro import should be fixed somehow.)
I don't think we want at all, really. If we want to import macros, we should have another means of doing it. Otherwise we have an inconsistency. So yes, I think I agree with your last paragraph above all,
I've discussed this a bit in the tracking issue for the macros import system:
Thanks, you expressed the exact concern I had in a concise way.
Another thing this needs to lint is unlisted crates that are included in that clash with existing modules. I'm not quite sure on what the story needs to be here cc
Does it? I've thought one of the things the path clarity RFC was about was to have separate namespaces for top level modules and extern crates.
The current plan has changed a bit so I'm not sure if that is still true. (If stuff does change it will probably be RFCd again, there's a bit of experimentation going on)
Sigh I hope we won't discuss all of this crap all over again... I don't enjoy that but it is not me who wants to change things.
I've hidden your last comment, which I found hostile and unconstructive.
IDK what has been hearing, but for me, this is the latest state of consensus on that issue, and it seems to have separate namespaces: is that the case? You seem unresponsive on IRC that's why I'm using github.
That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc. Everything has been implemented.


Question: //~^ ERROR generic associated types are unstable type Pointer2<T>: Deref<Target = T> where T: Clone, U: Clone; //~^ ERROR generic associated types are unstable <ins> //~| ERROR where clauses on associated types are unstable </ins> } struct Foo;

clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24


Question: } } <del> if dont_insert_main || already_has_main { </del> <ins> // FIXME: This code cannot yet handle no_std test cases yet if dont_insert_main || already_has_main || prog.contains("![no_std]") { </ins> prog.push_str(everything_else); } else { <del> prog.push_str("fn main() {n"); </del> <ins> let returns_result = everything_else.trim_end().ends_with("(())"); let (main_pre, main_post) = if returns_result { ("fn main() { fn _inner() -> Result<(), impl core::fmt::Debug> {", "}n_inner().unwrap() }") } else { ("fn main() {n", "n}") }; prog.extend([main_pre, everything_else, main_post].iter().cloned()); </ins> line_offset += 1; <del> prog.push_str(everything_else); prog.push_str("n}"); </del> } debug!("final doctest:n{}", prog);

Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?


Question: fn raw_proc_macro(&self, id: DefIndex) -> &ProcMacro { // DefIndex's in root.proc_macro_data have a one-to-one correspondence <del> // with items in 'raw_proc_macros' </del> <ins> // with items in 'raw_proc_macros'. // NOTE: If you update the order of macros in 'proc_macro_data' for any reason, // you must also update src/libsyntax_ext/proc_macro_harness.rs // Failing to do so will result in incorrect data being associated // with proc macros when deserialized. </ins> let pos = self.root.proc_macro_data.unwrap().decode(self).position(|i| i == id).unwrap(); &self.raw_proc_macros.unwrap()[pos] }

The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)


Question: | LL |         Enum::Foo(a, b) => {} |         ^^^^^^^^^^^^^^^ not a tuple struct or tuple variant <ins> | help: the struct variant's fields are being ignored | LL |         Enum::Foo { a: _, b: _ } => {} |                   ~~~~~~~~~~~~~~ </ins> error[E0769]: tuple variant `Enum::Bar` written as struct variant --> $DIR/recover-from-bad-variant.rs:12:9


Question: font-size: 19px; } <ins> ul.item-list > li > .out-of-band { font-size: 19px; } </ins> h4 > code, h3 > code, .invisible > code { position: inherit; }

It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .


Question: // We replace self[index] with the last element. Note that if the // bounds check above succeeds there must be a last element (which // can be self[index] itself). <del> let last = ptr::read(self.as_ptr().add(len - 1)); let hole = self.as_mut_ptr().add(index); </del> <ins> let value = ptr::read(self.as_ptr().add(index)); let base_ptr = self.as_mut_ptr(); ptr::copy(base_ptr.add(len - 1), base_ptr.add(index), 1); </ins> self.set_len(len - 1); <del> ptr::replace(hole, last) </del> <ins> value </ins> } }

The following code : run under miri reports UB:
cc
The underlying issue is in : this has the same error.
This is actually tricky, I think -- an unexpected consequence of the Stacked Borrows rules. When is being passed to , it gets reborrowed and then "protected", meaning the mutable reference passed to must outlive that function call. But then it goes ahead and reads the old reference from directly via the raw pointer, which reborrows that reference, therefore invalidating the earlier other reborrow. There is a sense in which the reborrow of passed to is truly invalidated here -- and in fact it is not possible to access that value later: I am surprised by this error, since usually mutable references are reborrowed, not moved. But it seems here it somehow knows not to reborrow?
cc -- could be related? Fully-qualifying the call with yields a different error (where reborrowed rather than moved), so it seems at least partially related:
Ah, yes that's it. Not that the exact error makes such a big difference, but now at least it is more clear that the reborrow makes later uses of fail.
Type inference will prevent reborrowing from happening.
Could we say that a mutable reference that comes from a type parameter shouldn't be protected?
That seems a bit strange, to have a particular instance of a generic function behave differently than if that same instance had been written monomorphically.
Well, generic function is different from an monomorphic function. In a monomorphic function you can dereference the reference, but (if there're no bounds) then in generic function you just have and would need to treat it "just as data" and the fact it's monomorphized to be a reference shouldn't be special. I.e. I would expect a to behave more closely to or than a dedicated, say type. It is strange to me that two monomorphized versions of the same function should behave differently.
Sure, a monomorphic function can be changed to do more things. But when a generic and monomorphic function are the same in the source code, they also should behave the same. They use completely different types, so them behaving the same does not even make sense? Like, e.g., will literally return different values. In general, two monomorphized versions of the same function have no choice but to behave differently.


Question: // We replace self[index] with the last element. Note that if the // bounds check above succeeds there must be a last element (which // can be self[index] itself). <del> let last = ptr::read(self.as_ptr().add(len - 1)); let hole = self.as_mut_ptr().add(index); </del> <ins> let value = ptr::read(self.as_ptr().add(index)); let base_ptr = self.as_mut_ptr(); ptr::copy(base_ptr.add(len - 1), base_ptr.add(index), 1); </ins> self.set_len(len - 1); <del> ptr::replace(hole, last) </del> <ins> value </ins> } }

To give another example, if you a to , then again of course this is UB for some (e.g., ) but totally fine for others (e.g., ).


Question: /// Swaps the values of two `Cell`s. /// Difference with `std::mem::swap` is that this function doesn't require `&mut` reference. /// <ins> /// # Panics /// /// This function will panic if `self` and `other` are different `Cell`s that partially overlap. /// (Using just standard library methods, it is impossible to create such partially overlapping `Cell`s. /// However, unsafe code is allowed to e.g. create two `&Cell<[i32; 2]>` that partially overlap.) /// </ins> /// # Examples /// /// ```

In , it was uncovered that is making some rather strong assumptions: two s with different address but the same type must not overlap. Not only is this a scarily non-local safety invariant, it is also fundamentally incomaptible with some APIs that ought to be correct, as demonstrated by this snippet (thanks to and for help with working out the example): to see the issue: will duplicate parts of the memory range when there is overlap, which leads to double-drop (other parts of the memory range are just lost, leading to memory leaks, but that is not the main issue here). This is not itself a soundness issue as it requires unsafe code to trigger UB. But this likely reflects an unintended consequence of . This got stabilized in as part of That commit references and an RFC, but is not mentioned in either of them. was in Accept that is unsound and document "non-overlap" as part of the safety invariant. This seems very fragile. Make not misbehave on overlap, either by panicking or by only swapping the non-overlapping parts. Cc
was in , which was authored by a "Charlie Fan". This is probably
Cc
This makes the method sound, but it seems like there could be other seems-like-they-should-be-ok cell projections that break under this behavior.
I don't think so. This makes the function behave "strangely", but since no data is duplicated nor discarded, I think it is sound.
I share this hunch, although the code, out of nowhere, may look very contrived. Consider: So it seems like -king (at least for non- types) is the only option that would allow us too keep the structural property of s, which, imho, is a very intuitive programmer mindset (and thus, a mistake that many would do should they not know about this caveat), and so a quite important thing to preserve .
That is an example of the "strange" behavior not being the right thing for this code, but it is not an unsoundness of per se. Your unsafe code is simply making wrong assumptions about the functional behavior of . Current favors the first operand in case of overlap (according to documentation); unsafe code that incorrectly assumes it would favor the second operand would be equally wrong. I don't see a bug in either way. IMO it seems rather strange to only panic for non- types.