jiebi/CodeConvo huggingface dataset:
Change:
for elem in place_ref.projection[base..].iter() { cg_base = match elem.clone() { mir::ProjectionElem::Deref => { <del> // custom allocators can change box's abi, making it unable to be derefed directly if cg_base.layout.ty.is_box() && matches!(cg_base.layout.abi, Abi::Aggregate { .. } | Abi::Uninhabited) { </del> <ins> // a box with a non-zst allocator should not be directly dereferenced if cg_base.layout.ty.is_box() && !cg_base.layout.field(cx, 1).is_zst() { </ins> let ptr = cg_base.project_field(bx, 0).project_field(bx, 0); bx.load_operand(ptr).deref(bx.cx())

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. --Only when building with or do I trigger this issue. Found while working on . Compile test that triggers the issue: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: +A-allocators +A-lto
claim
claim
Hey thanks for looking into this bug (and for fixing my last reports as well :)). I've figured out some more information since first posting this. I'm able to reproduce the bug in a single crate when compiling with 1 and further minimized the triggering code: The bug seems to be specifically triggered when the allocator is non zero-sized, it doesn't matter whether it's a reference or not. Additionally if the boxed type is a struct or tuple, only accessing past the first non-zero field triggers the bug. Attempting to disassemble the bitcode dumped with with gives the same error, unless I pass the flag which causes the disassembly to succeed. The offending store instruction is encoded as follows: Unfortunately the flag strips all pointer types from the input, turning them to in the output, so I do not know what the original type was that is causing the issue. Using the following which doesn't trigger the issue: without gives:
Thanks for the info and minimized code! That's gonna make this easier.
I still don't know how this actually happens, I just know that the change in fixes it. I suspect it's some code assuming that a wide box is always a wide pointer, but I don't know where...
I think you're right about that assumption, using a wide pointer in the box has no issues:
Change:
traits.push(TraitInfo::new(did)); } decoder::DlDef(def::DefMod(did)) => { <ins> if !external_mods.insert(did) { return; } </ins> csearch::each_child_of_item(cstore, did, |dl, _, _| { <del> handle_external_def(traits, ccx, cstore, dl) </del> <ins> handle_external_def(traits, external_mods, ccx, cstore, dl) </ins> }) } _ => {}

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
// compile-flags: --test #![feature(async_closure)] <ins> #![feature(auto_traits)] </ins> #![feature(box_patterns)] #![feature(const_trait_impl)] #![feature(decl_macro)]

Discussion:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.
Change:
<ins> // compile-flags: -Zsave-analysis use {self}; //~ ERROR E0431 fn main () { } </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. --<!-- 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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

<!-- 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. --reduced from <!-- 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<!-- 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. --code from <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one: another one:
I am on it
Same issue happened after upgraded to the latest version today.
Yes the has not landed yet.
Change:
// CHECK-NEXT: define void @naked_with_args(i{{[0-9]+( %0)?}}) pub fn naked_with_args(a: isize) { // CHECK-NEXT: {{.+}}: <del> // CHECK-NEXT: %a = alloca i{{[0-9]+}} </del> <ins> // CHECK-NEXT: %_1 = alloca i{{[0-9]+}} </ins> &a; // keep variable in an alloca // CHECK: ret void }

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
<ins> error: unknown diagnostic attribute --> $DIR/deny_malformed_attribute.rs:3:15 | LL | #[diagnostic::unknown_attribute] |               ^^^^^^^^^^^^^^^^^ | note: the lint level is defined here --> $DIR/deny_malformed_attribute.rs:1:9 | LL | #![deny(unknown_or_malformed_diagnostic_attributes)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this
Change:
cargo_subcommand(builder.kind), ); rustc_cargo(builder, &mut cargo, target); <del> if let Subcommand::Check { all_targets: true, .. } = builder.config.cmd { cargo.arg("--all-targets"); } </del> <ins> cargo.arg("--all-targets"); </ins> // Explicitly pass -p for all compiler krates -- this will force cargo // to also check the tests/benches/examples for these crates, rather

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
| = note: expected `async` closure body `{async closure body@$DIR/coroutine-desc.rs:14:19: 14:21}` found `async` closure body `{async closure body@$DIR/coroutine-desc.rs:14:36: 14:38}` <ins> = note: no two async blocks, even if identical, have the same type = help: consider pinning your async block and casting it to a trait object </ins> note: function defined here --> $DIR/coroutine-desc.rs:8:4 |

Discussion:
Especially for people new to async, this message is extremely opaque. There is not actually enough information to understand it unless you already know (a) that async blocks produce an anonymous future type and (b) that regardless of the type, those futures are always unique and incompatible types. The message sort of implies this (“found a different block”), but it is not actionable in any way. It is pretty easy to get here by reaching for (to pick just one easy example) . I ended up stumbling across it in the process of building up some sample code for the new async chapter in , and I had a moment at first! I have the time to help fix this, so if someone can point me in the right direction and help get it landed, I would be delighted to do the work. No response No response_
This seems like a good suggestion. I'd suggest tweaking the wording a bit, since I don't know that the implications of async blocks having unique types are immediately obvious. Maybe something like this?
labels +AsyncAwait-Triaged We discussed this in our async call and agreed that some improvement along these lines would be good. We could wordsmith it in the PR of course. (It'd be interesting too to add such diagnostics for closures and other similar cases.)
For reference, here's the error message for mismatched s (). Perhaps borrowing from this phrasing could be helpful here?
Change:
<ins> -include ../tools.mk # FIXME: ignore freebsd/windows # (windows: see `../dep-info/Makefile`) ifneq ($(shell uname),FreeBSD) ifndef IS_WINDOWS all: $(RUSTC) --dep-info $(TMPDIR)/custom-deps-file.d --crate-type=lib lib.rs sleep 1 touch 'foo foo.rs' -rm -f $(TMPDIR)/done $(MAKE) -drf Makefile.foo rm $(TMPDIR)/done pwd $(MAKE) -drf Makefile.foo rm $(TMPDIR)/done && exit 1 || exit 0 else all: endif else all: endif </ins>

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
om.foreigns.push((item, renamed)); } } <del> // Convert each `exported_macro` into a doc item. fn visit_local_macro(&self, def: &'tcx hir::MacroDef<'_>, renamed: Option<Symbol>) -> Macro { debug!("visit_local_macro: {}", def.ident); let tts = def.ast.body.inner_tokens().trees().collect::<Vec<_>>(); // Extract the spans of all matchers. They represent the "interface" of the macro. let matchers = tts.chunks(4).map(|arm| arm[0].span()).collect(); Macro { def_id: self.cx.tcx.hir().local_def_id(def.hir_id).to_def_id(), name: renamed.unwrap_or(def.ident.name), matchers, imported_from: None, } } </del> }

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
<ins> // check-pass macro_rules! m { () => { /// A //~^ WARNING #[path = "auxiliary/module_macro_doc.rs"] pub mod mymodule; } } m!(); </ins>

Discussion:
: : I expected to see this happen: completes successfully with a "unresolved link to " warning Instead, this happened: <!-- 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 bet the source span is wrong somehow.
The issue is that the documentation on the re-export is being combined with the original documentation. splits it up by the module it's scoped to, which is different for the two doc-comments; if you remove it works fine. needs to only pass the documentation for the current scope to , not the combined docs. Not sure why it needs a separate file.
The markdown range it comes up with is 3..13. Hmm, this is weird - I think this is actually the correct span because they both come from , which doesn't care about scoping and just works on strings. Maybe it is a bug in after all?
Aha, here we go: is trying to look at the rustc snippet instead of the text it was provided. Maybe it could just work with instead?
Hmm, there are some other bugs here too: normally rustdoc will resolve docs in the scope inside the module and to the scope of the parent. But since there are inner docs, it will resolve all of the links inside the module. I think the fix for both the issues is to separate outer docs from inner ones; not yet sure how to do that.
To add another test-case for what I believe is another instance of the same problem: This doesn't panic, but produces: For an even more confused case, split the module into its own file: Which yields this nonsensical warning: Essentially, the span of the unresolved link is misattributed to the wrong file. The line and column values are correct, it's just the wrong file that's used.
That's is assuming there is only inner or outer docs, not both.
Change:
error[E0005]: refutable pattern in local binding <del> --> $DIR/uninhabited-irrefutable.rs:27:9 </del> <ins> --> $DIR/uninhabited-irrefutable.rs:29:9 </ins> | LL |     let Foo::D(_y, _z) = x; |         ^^^^^^^^^^^^^^ pattern `Foo::A(_)` not covered

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
<del> error[E0433]: failed to resolve: unresolved import --> $DIR/suggest-import-issue-120074.rs:10:35 | LL |     println!("Hello, {}!", crate::bar::do_the_thing); |                                   ^^^ unresolved import | help: a similar path exists | LL |     println!("Hello, {}!", crate::foo::bar::do_the_thing); |                                   ~~~~~~~~ help: consider importing this module | LL + use foo::bar; | help: if you import `bar`, refer to it directly | LL -     println!("Hello, {}!", crate::bar::do_the_thing); LL +     println!("Hello, {}!", bar::do_the_thing); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;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<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.
Change:
<ins> #![feature(arbitrary_self_types)] use std::ops::Deref; struct Foo(u32); impl Foo { fn get<R: Deref<Target=Self>>(self: R) -> u32 { self.0 } } fn main() { let mut foo = Foo(1); foo.get::<&Foo>(); //~^ ERROR mismatched types } </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. --<!-- 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
label +F-arbitraryselftypes