jiebi/CodeConvo huggingface dataset:
Change:
fn visit_anon_const(&mut self, c: &'a ast::AnonConst) { run_early_pass!(self, check_anon_const, c); <ins> self.check_id(c.id); </ins> ast_visit::walk_anon_const(self, c); }

Discussion:
<!-- 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. --After testing, it's this macro here: The semicolon in the third variant causes the error when used in a context such as: Note that prior to updating I was using , which did not error. This errors on Nightly and Stable, I tested both ( and both have the same result). Removing the semicolon causes the project to build fine and function as it did before updating. : This error is repeated over and over again before the notification saying to submit the bug report <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Can you share the original repository, or provide a self-contained reproduction of the issue?
here is one I got to error in the same way: I also noticed this warning that I believe I failed to include in the original issue: If I remove the semicolon, this warning does not show up, and the program works as expected.
Change:
let mut infer_args_for_err = FxHashSet::default(); <ins> let mut explicit_late_bound = ExplicitLateBound::No; </ins> for &PathSeg(def_id, index) in &path_segs { let seg = &segments[index]; let generics = tcx.generics_of(def_id);

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
<ins> const EXPECTED = [ { 'query': 'pid_t', 'correction': null, 'proposeCorrectionFrom': null, 'proposeCorrectionTo': null, 'others': [ { 'path': 'underscoredtype::unix', 'name': 'pid_t' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'set_pid' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'get_pid' }, ], }, { 'query': 'pidt', 'correction': 'pid_t', 'proposeCorrectionFrom': null, 'proposeCorrectionTo': null, 'others': [ { 'path': 'underscoredtype::unix', 'name': 'pid_t' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'set_pid' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'get_pid' }, ], }, { 'query': 'unix::pid_t', 'correction': null, 'proposeCorrectionFrom': null, 'proposeCorrectionTo': null, 'others': [ { 'path': 'underscoredtype::unix', 'name': 'pid_t' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'set_pid' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'get_pid' }, ], }, { 'query': 'unix::pidt', 'correction': 'pid_t', 'proposeCorrectionFrom': null, 'proposeCorrectionTo': null, 'others': [ { 'path': 'underscoredtype::unix', 'name': 'pid_t' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'set_pid' }, ], 'returned': [ { 'path': 'underscoredtype::unix', 'name': 'get_pid' }, ], }, ]; </ins>

Discussion:
The "In Names" search tab is fine, but the "In Parameters" and "In Return Types" have the confusing note that ! label: +T-rustdoc +A-rustdoc-ui
Change:
= help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: where clauses on associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:30:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:31:5 </ins> | LL |     type Assoc where Self: Sized; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable <del> error: aborting due to 6 previous errors </del> <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:36:5 | LL |     type Assoc where Self: Sized = Foo; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable error: aborting due to 7 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
#![unstable(feature = "wasi_ext", issue = "71213")] <ins> // NOTE: despite the fact that this module is unstable, // stable Rust had the capability to access the stable // re-exported items from os::fd::raw through this // unstable module. // In PR #95956 the stability checker was changed to check // all path segments of an item rather than just the last, // which caused the aforementioned stable usage to regress // (see issue #99502). // As a result, the items in os::fd::raw were given the // rustc_allowed_through_unstable_modules attribute. // No regression tests were added to ensure this property, // as CI is not configured to test wasm32-wasi. // If this module is stabilized, // you may want to remove those attributes // (assuming no other unstable modules need them). </ins> pub use crate::os::fd::raw::*;

Discussion:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.
Change:
<del> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++-multilib  make  file  curl  ca-certificates  python2.7  git  cmake  xz-utils  sudo  gdb  patch  libssl-dev  pkg-config WORKDIR /build/ COPY musl-libunwind-patch.patch build-musl.sh /build/ RUN sh /build/build-musl.sh && rm -rf /build RUN curl -OL https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64.deb &&  dpkg -i dumb-init_*.deb &&  rm dumb-init_*.deb ENTRYPOINT ["/usr/bin/dumb-init", "--"] RUN curl -o /usr/local/bin/sccache  https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-02-25-sccache-x86_64-unknown-linux-musl &&  chmod +x /usr/local/bin/sccache ENV RUST_CONFIGURE_ARGS  --target=x86_64-unknown-linux-musl,i686-unknown-linux-musl,i586-unknown-linux-gnu  --musl-root-x86_64=/musl-x86_64  --musl-root-i686=/musl-i686 # Newer binutils broke things on some vms/distros (i.e., linking against # unknown relocs disabled by the following flag), so we need to go out of our # way to produce "super compatible" binaries. # # See: https://github.com/rust-lang/rust/issues/34978 ENV CFLAGS_i686_unknown_linux_musl=-Wa,-mrelax-relocations=no  CFLAGS_x86_64_unknown_linux_musl=-Wa,-mrelax-relocations=no ENV SCRIPT  python2.7 ../x.py test  --target x86_64-unknown-linux-musl  --target i686-unknown-linux-musl  --target i586-unknown-linux-gnu  &&  python2.7 ../x.py dist  --target x86_64-unknown-linux-musl  --target i686-unknown-linux-musl  --target i586-unknown-linux-gnu </del>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
simplify::remove_dead_blocks(&mut body); // Update the body's def to become the drop glue. <del> // This needs to be updated before the AbortUnwindingCalls pass. </del> let coroutine_instance = body.source.instance; let drop_in_place = tcx.require_lang_item(LangItem::DropInPlace, None); let drop_instance = InstanceDef::DropGlue(drop_in_place, Some(coroutine_ty)); <del> body.source.instance = drop_instance; pm::run_passes_no_validate( tcx, &mut body, &[&abort_unwinding_calls::AbortUnwindingCalls, &add_call_guards::CriticalCallEdges], None, ); </del> // Temporary change MirSource to coroutine's instance so that dump_mir produces more sensible // filename.

Discussion:
<!-- 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. -- <p<details</p</details<!-- 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</detailsBuild with
can reproduce
can you include a and (for example as a link to a project (+commit), or right here), to be able to reproduce this in the future?
Sorry, forgot to add those, I've attached them
does needs MCVE mean an example not relying on tokio?
yes
Ran a bisect. searched nightlies: from to regressed nightly: searched commit range: ... regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Spent some unforgettable time chopping down 80k lines of tokio code piece by piece, but it was worth it, I hope. Here's an MCVE: : :
Since this seems to be somehow caused by mir drop tracking, cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> error[E0432]: unresolved import `doesnt_exist` --> $DIR/issue-81413.rs:7:9 | LL | pub use doesnt_exist::*; |         ^^^^^^^^^^^^ maybe a missing crate `doesnt_exist`? | = help: consider adding `extern crate doesnt_exist` to use the `doesnt_exist` crate error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </ins>

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. --I tried this code: () I expected to see an error that only says that " is unresolved". But the error says that all uses of items from the module with glob import ( in this case) are unresolved too: This may lead to extremely long and unreadable errors. The issue was originally found while developing where it caused . <!-- 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. --:
<details<summaryOutput on 1.38:</summary</details label A-diagnostics A-resolve regression-from-stable-to-stable
why do you think it's a "regression-from-stable-to-stable"? IMO the output from is even worse
The error is much shorter, and only points at the actual problem. The unused import warnings, of course, wouldn't be there if those imports were actually used.
From those rollups, looks relevant.
ah, you are right, I've misread the output thinking that the warnings were errors too.
I spent some time trying to debug this last week and I'm fairly sure is the PR that introduced this. I wasn't aware of that PR at the time but I spent a lot of time trying to understand what is "determinate" vs. "indeterminate" (which is unfortunately not documented) and I remember finding out that with glob import the import is becoming "indeterminate" while it's normally (without the glob import) it is "determinate", which is one of the things we check elsewhere when generating these warnings.
Assigning as and removing .
Change:
<ins> trait Bar { const X: usize; fn return_n(&self) -> [u8; Bar::X]; //~ ERROR: type annotations needed } impl dyn Bar {} //~ ERROR: the trait `Bar` cannot be made into an object fn main() {} </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "lp64d".into(), max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_gnu::opts() }, }

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
<ins> // build-pass // compile-flags: -Cdebuginfo=2 // fixes issue #94725 #![feature(allocator_api)] use std::alloc::{AllocError, Allocator, Layout}; use std::ptr::NonNull; struct ZST; unsafe impl Allocator for &ZST { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> { todo!() } unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { todo!() } } fn main() { let _ = Box::<i32, &ZST>::new_in(43, &ZST); } </ins>

Discussion:
<!-- 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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim
Change:
.and_then(|ur_vid| self.definitions[*ur_vid].external_name) .unwrap_or(infcx.tcx.lifetimes.re_root_empty), ty::ReLateBound(..) => region, <ins> ty::ReStatic => region, </ins> _ => { infcx.tcx.sess.delay_span_bug( span,

Discussion:
Trying to build  0.2.5 with latest nightly results in an ICE. Bisected the regression to , cc I have tried to minimize it. This still requires 0.3, I'm not sure how to minimize if further. <!-- 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
Seems like a duplicate of
I don't think that is related, neither the error matches nor is it a recent regression. Did you link the wrong issue? fixes this ICE
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Still needs a backport
(assigning self to ensure backport happens.)
Also seen in the latest (): zebra-consensus: https://crater- warp v0.3.1: https://crater- linkerd: https://crater- Along with a number of others.
Backport () was merged.
Change:
let forbidden_lint_name = match forbid_src { LintSource::Default => id.to_string(), LintSource::Node(name, _, _) => name.to_string(), <del> LintSource::CommandLine(name) => name.to_string(), </del> <ins> LintSource::CommandLine(name, _) => name.to_string(), </ins> }; let (lint_attr_name, lint_attr_span) = match *src { LintSource::Node(name, span, _) => (name, span),

Discussion:
<!-- 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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
}; let mut sugg = Vec::with_capacity(2); let mut inner_expr = expr; <ins> let mut is_raw_ptr = false; let typeck_result = self.infcx.tcx.typeck(self.mir_def_id()); </ins> // Remove uses of `&` and `*` when suggesting `.clone()`. while let hir::ExprKind::AddrOf(.., inner) | hir::ExprKind::Unary(hir::UnOp::Deref, inner) = &inner_expr.kind

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.