jiebi/CodeConvo huggingface dataset:
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro_quote)] extern crate proc_macro; use proc_macro::{quote, TokenStream}; #[proc_macro_attribute] pub fn hello(_: TokenStream, _: TokenStream) -> TokenStream { quote!( fn f(_: &mut i32) {} fn g() { f(123); } ) } </ins>

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
// overlapping locations. let mut dup_vec: Vec<_> = repeat(u32::MAX).take(self.num_vars() as usize).collect(); <del> let mut opt_graph = None; </del> for idx in 0..self.num_vars() as usize { match var_data[idx].value { Value(_) => {

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
<ins> // edition: 2021 // If the span extractor can't find any relevant spans for a function, // but the function contains coverage span-marker statements (e.g. inserted // for `if !`), coverage codegen may think that it is instrumented and // consequently complain that it has no spans. // // Regression test for <https://github.com/rust-lang/rust/issues/118850>, // "A used function should have had coverage mapping data but did not". fn main() { affected_function(); } macro_rules! macro_that_defines_a_function { (fn $name:ident () $body:tt) => { fn $name () $body } } macro_that_defines_a_function! { fn affected_function() { if !false { () } else { () } } } </ins>

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
construct_unstable_allow!(0); |x: internal_unstable::Foo| { call_method_allow!(x) }; |x: internal_unstable::Bar| { access_field_allow!(x) }; <ins> |x: internal_unstable::Bar| { access_field_allow2!(x) }; // regression test for #77088 </ins> // bad. pass_through_allow!(internal_unstable::unstable()); //~ ERROR use of unstable

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
const TAG_OS: usize = 0b10; const TAG_SIMPLE: usize = 0b11; <ins> /// The internal representation. /// /// See the module docs for more, this is just a way to hack in a check that we /// indeed are not unwind-safe. /// /// ```compile_fail,E0277 /// fn is_unwind_safe<T: core::panic::UnwindSafe>() {} /// is_unwind_safe::<std::io::Error>(); /// ``` </ins> #[repr(transparent)] <del> pub(super) struct Repr(NonNull<()>); </del> <ins> pub(super) struct Repr(NonNull<()>, PhantomData<ErrorData<Box<Custom>>>); </ins> // All the types `Repr` stores internally are Send + Sync, and so is it. unsafe impl Send for Repr {}

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
<ins> // Copyright 2013 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. pub struct UninterpretedOption_NamePart { name_part: Option<~str>, } impl<'a> UninterpretedOption_NamePart { pub fn default_instance() -> &'static UninterpretedOption_NamePart { static instance: UninterpretedOption_NamePart = UninterpretedOption_NamePart { name_part: None, }; &'static instance } } pub fn main() {} </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 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. pub struct UninterpretedOption_NamePart { name_part: Option<~str>, } impl<'a> UninterpretedOption_NamePart { pub fn default_instance() -> &'static UninterpretedOption_NamePart { static instance: UninterpretedOption_NamePart = UninterpretedOption_NamePart { name_part: None, }; &'static instance } } pub fn main() {} </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
<ins> error: cannot determine resolution for the import --> $DIR/shadow-glob-module-resolution-3.rs:11:5 | LL | use b::c; |     ^^^^ error: cannot determine resolution for the import --> $DIR/shadow-glob-module-resolution-3.rs:11:5 | LL | use b::c; |     ^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0432]: unresolved import `b::c` --> $DIR/shadow-glob-module-resolution-3.rs:11:5 | LL | use b::c; |     ^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0432`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' File: --auto-reduced (treereduce-rust): original: 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --auto-reduced (treereduce-rust): original: 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
} } PathSource::Expr(_) | PathSource::TupleStruct(..) | PathSource::Pat => { <del> let span = match &source { PathSource::Expr(Some(Expr { span, kind: ExprKind::Call(_, _), .. })) | PathSource::TupleStruct(span, _) => { // We want the main underline to cover the suggested code as well for // cleaner output. err.set_span(*span); *span } _ => span, }; </del> <ins> let span = find_span(&source, err); </ins> if let Some(span) = self.def_span(def_id) { err.span_label(span, &format!("`{}` defined here", path_str)); }

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
let module = hir.as_local_hir_id(id.to_def_id()).unwrap(); &tcx.untracked_crate.modules[&module] }; <del> providers.hir_owner = |tcx, id| tcx.index_hir(LOCAL_CRATE).map[id].signature.unwrap(); providers.hir_owner_nodes = |tcx, id| { tcx.index_hir(LOCAL_CRATE).map[id].with_bodies.as_ref().map(|nodes| &**nodes).unwrap() }; </del> <ins> providers.hir_owner = |tcx, id| tcx.index_hir(LOCAL_CRATE).map[id].signature; providers.hir_owner_nodes = |tcx, id| tcx.index_hir(LOCAL_CRATE).map[id].with_bodies.as_ref().map(|nodes| &**nodes); </ins> map::provide(providers); }

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
|                 return type in trait error[E0053]: method `bar` has an incompatible type for trait <del> --> $DIR/opaque-and-lifetime-mismatch.rs:11:17 </del> <ins> --> $DIR/opaque-and-lifetime-mismatch.rs:10:17 </ins> | LL |     fn bar() -> i32 { |                 ^^^

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '', 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Okay, lol, here the types obviously do unify and therefore isn't effective in this situation.
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call if we have which is the case because generated one because the HIR (!) type visitor inside found an opaque type in the HIR type (here ) while the lowered type (here ) no longer contains any opaque types ultimately leading to the assert triggering. In short: visit the HIR ty , see an opaque type and take note of that synthesize an assoc ty for the RPITIT (I think) because of (1) lower the ty to due to the argument kind mismatch try to collect RPITITs on the lowered type & fail to find the opaque type I don't know if this is actually useful in general :thinking: What kinds of bugs is it supposed to catch?
cc
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).

Yeah, this assertion was simply there to make sure we weren't incorrectly calling for methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it uses rather than in the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.
We could also delay a bug on mismatch
Change:
// the common code. use std::hashmap::{HashMap, HashSet}; <ins> use std::io::Decorator; </ins> use EBReader = extra::ebml::reader; use EBWriter = extra::ebml::writer;

Discussion:
The bots are currently failing like so I bisected to , which changes how works.
Closing since I'm almost certain that test is either gone, or passes.
This continues to be a source of breakage on incoming. Right now the failure is in rpass/auto-encode
run-pass/auto-encode is xfailed now
my branch contains a reduced test case under run-pass/issue-6122
incoming has been poofed, so I'm not sure what the status of this is. Bors has been churning away and the tree is green, so does the problem still arise?
The test passes locally for me with some updating. Pushed it to try, will see how it falls.
Change:
// for `-Z gcc-ld=lld` let gcc_ld_dir = libdir_bin.join("gcc-ld"); t!(fs::create_dir(&gcc_ld_dir)); <del> builder.copy( &lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld", target_compiler.host)), ); builder.copy( &lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld64", target_compiler.host)), ); </del> <ins> for flavor in ["ld", "ld64"] { let lld_wrapper_exe = builder.ensure(crate::tool::LldWrapper { compiler: build_compiler, target: target_compiler.host, flavor_feature: flavor, }); builder.copy(&lld_wrapper_exe, &gcc_ld_dir.join(exe(flavor, target_compiler.host))); } </ins> } // Similarly, copy `llvm-dwp` into libdir for Split DWARF. Only copy it when the LLVM

Discussion:
Checked that on target, found duplicates in versions: and <strikeno duplicates</strike2 duplicates (<strikeonly</strike, ) in stable , (bisecting is kinda slow on my connection) there 3 copies of that executable, that gives ~ 187mb label +regression-from-stable-to-beta
Can be found in:
I think they were in and . I believe is also a copy of .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
claim
Sorry, I only came across this issue just now. The copies are there for a reason, see linked issues. Multiple things to consider: The files in the directory are only used with the unstable option. So they could be removed for beta and stable. They can be replaced with small Rust executables which just exec and respectively. I will be working on that for nightly.