jiebi/CodeConvo huggingface dataset:
Change:
= note: each usage of a `const` item creates a new temporary = note: the mutable reference will refer to this temporary, not the original `const` item note: `const` item defined here <del> --> $DIR/lint-const-item-mutation.rs:12:1 </del> <ins> --> $DIR/lint-const-item-mutation.rs:13:1 </ins> | <del> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'] }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'], raw_ptr: 2 as *mut u8 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> warning: taking a mutable reference to a `const` item <del> --> $DIR/lint-const-item-mutation.rs:20:5 </del> <ins> --> $DIR/lint-const-item-mutation.rs:22:5 </ins> | LL |     (&mut MY_STRUCT).use_mut(); |     ^^^^^^^^^^^^^^^^

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 have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
<ins> // Test for issue #67776: binding named the same as enum variant // should report a warning even when matching against a reference type // check-pass #![allow(unused_variables)] #![allow(non_snake_case)] enum Foo { Bar, Baz, } fn fn1(e: Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn fn2(e: &Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn fn3(e: &mut &&mut Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn main() {} </ins>

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This lint was generated by : as we can see is just ignored, so the fix is pretty easy, just all the refs in the type of .
claim
Change:
assert!(foo as usize != bar as usize); <del> assert_eq!(foo as i16, foo as usize as i16); </del> <ins> // Taking a few bits of a function's address is totally pointless and we detect that // Disabling the lint to ensure that the assertion can still be run #[allow(const_err)] { assert_eq!(foo as i16, foo as usize as i16); } </ins> // fptr-ptr-cast

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
/// /// /// ```rust <del> /// # #![feature(return_position_impl_trait_in_trait)] </del> /// use core::future::Future; /// pub trait Trait { ///     fn method(&self) -> impl Future<Output = ()> + Send { async {} }

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 +E-needs-mcve
Minimized to:
might be similar to , cc who self-assigned and probably knows more about this stuff ^^
in case we need more code snippets, here are 60 of them that that can trigger the ice in some way or another :upsidedownface:
I'm pretty sure all (or at least most) of these examples are not related. This issue is specifically the case where the code used to emit: and now ICEs. is unrelated except for the ICE message.
Ah so this () is a new one? Need to put some though into automatic ice distinction (perhaps based on query stack?)
Yeah, there's a class of ICEs that have the same name and often very different root causes (i.e. ICEs in snapshot-vec) and this is one of them.
Change:
<ins> // Regression test for #87549. // compile-flags: -C incremental=tmp/wf/hir-wf-check-erase-regions pub struct Table<T, const N: usize>([Option<T>; N]); impl<'a, T, const N: usize> IntoIterator for &'a Table<T, N> { type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; //~ ERROR `&T` is not an iterator type Item = &'a T; fn into_iter(self) -> Self::IntoIter { //~ ERROR `&T` is not an iterator unimplemented!() } } 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn chunks(&self, chunk_size: usize) -> Chunks<'_, T> { <del> assert!(chunk_size != 0); </del> <ins> assert_ne!(chunk_size, 0); </ins> Chunks { v: self, chunk_size } }

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
<del> //@ known-bug: #127880 //@ compile-flags: -Cinstrument-coverage #[coverage] fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected value of coverage attribute', 'error: internal compiler error: unexpected value of coverage attribute' 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: [coverageattron] checking for on [mirbuilt] building MIR for -- label +F-coverageattribute
Regression in
Change:
use std::io; use std::io::ErrorKind; use std::path::{Path, PathBuf}; <del> use std::process::Command; </del> <ins> use std::process::{Command, Stdio}; </ins> use std::str; use channel::GitInfo;

Discussion:
<details<summary<codegit --version --build-options</code</summary</detailsExample: <details<summary<codeD:tmpgit clone -o upstream</code</summary</details<details<summary<codeD:tmpcd rust</code</summary</details<details<summary<codemaster:rustpython setup</code</summary</details(continued) <details<summary<codemaster:rustgit show-ref HEAD</code</summary</details label +C-bug +A-bootstrap
Additional info: switching to a new branch that is not tracking upstream succeeds, so it is the upstream tracking that's messing something up: <details<summaryterminal session</summary
My current working theory is that this is a git bug (maybe we can work around it though). I think this is because git has created the submodule with a remote of , but probably due to the passed for the rust checkout, it's trying to fetch/pull from the upstream remote inside the submodule too. That won't work; the upstream remote doesn't exist there, as the submodule was initially cloned (via that same git submodule update) with an "origin" remote. I'm not sure what we should be doing to avoid this -- my guess is a proper fix would be in git itself... it might be that we can try to workaround it somehow, but I'm not seeing an obvious hook for us to attach to.
Can we report this bug upstream to git? I think they use a mailing list?
I was not able to reproduce this locally :/ I tried and it checked out the submodules successfully. I'm using
For me this happens only sometimes. Most of the time when I checkout an old branch. I think I've got a reproduction (by checking out an old commit and pushing a branch to my fork), probably has unnecessary steps, but it seems to be "working" for me. git version:
To make steps reproducible - HEAD is currently
Oh lol, I just ran into this today. A bit more info: <details</details
On the bright side, this means it's easy to work around the bug.
ah hmm, after doing that I can no longer reproduce the bug ... I think this might only happen on the very first submodule we try to clone?

git is acting so strangely ... this happens even in a fresh worktree, it's only when it's a fresh clone it hits this problem, which makes no sense to me since submodules aren't shared between worktrees. Anyway, here's a minimal reproduction that doesn't depend on exactly which commit you're using, or : I'll put up a PR shortly.
Change:
#[macro_export] #[stable(feature = "rust1", since = "1.0.0")] macro_rules! format { <del> ($($arg:tt)*) => ($crate::fmt::format(::core::format_args!($($arg)*))) </del> <ins> ($($arg:tt)*) => ($crate::fmt::format($crate::__export::format_args!($($arg)*))) </ins> }

Discussion:
Caused by . To be precise the change. It basically does: Because uses to refer to , it will try to resolve it in , which doen't contain .
cc
This regression affects another project I am working on as well. is there any status on this?
I'm not sure what the details of were, but this feels like a bug to me -- in particular it feels like the behavior here is less hygienic, not more? perhaps you can clarify your view on the situation, that'd be great.
Well, it's more hygienic than before because previously used whatever was closest in scope at the call site, while now it certainly uses from the crate named . (That doesn't make the change less breaking.) What really wants is to use def-site hygiene so that "the crate named " is searched from the 's definition point of view. (Not possible right now due to def-site hygiene for crates not being implemented.) In the meantime the change to can be reverted to fix the regression.
I see -- just not necessarily the core that was in scope at the point of definition. Seems right. Is there a tracking issue to cc or something?
That said, the constructions or (same, but from command line) really require some responsibility since they effectively override and . If you override them you should be able to provide all the necessary services expected from and , since for any third party macro is the only reliable way to refer to the standard library, at least until def-site hygiene is fully implemented and stabilized.
Is there a tracking issue to cc or something? This is supposed to be the tracking issue for the regression?
While most of the changes in 's PR have increased hygiene, the specific change linked by didn't do any increase (or decrease) as both times the macro is being resolved in an unhygienic way. From a pragmatic point of view, lots of people seem to shadow the core crate but few people want to (saying "want to" and not "do" because of selection bias) shadow the macro while wanting to use the builtin one for which is what the change now allows you to do. Furthermore, not breaking downstream users should always be a priority. It's not their fault that the format macro uses something in an unhygienic way. IMO the specific change should be reverted.

There is a pattern to use std or any other third party crate in a hygienic way. You define a in and then use to refer to std items in the macro.
Fixed in
check-in from compiler triage: marking as p-high, but has a pending fix already
Change:
hir_id, ) .0; <del> Some(DeadVariant { def_id, name: field.name, level }) </del> <ins> Some(DeadItem { def_id, name: field.name, level }) </ins> } else { None } }) .collect(); <del> visitor.warn_dead_fields_and_variants(def_id, "read", dead_fields, is_positional) </del> <ins> visitor.warn_multiple(def_id, "read", dead_fields, is_positional); </ins> } <del> visitor.warn_dead_fields_and_variants( item.owner_id.def_id, "constructed", dead_variants, false, ); </del> <ins> visitor.warn_multiple(item.owner_id.def_id, "constructed", dead_variants, false); </ins> } }

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
place) { trace!("checking whether {:?} can be stored to {:?}", value, local); if self.can_const_prop[local] { <del> trace!("storing {:?} to {:?}", value, local); assert!(self.get_const(local).is_none() || self.get_const(local) == Some(value)); self.set_const(local, value); </del> <ins> trace!("stored {:?} to {:?}", value, local); assert_eq!(self.get_const(local), Some(value)); </ins> if self.should_const_prop() { self.replace_with_const(

Discussion:
The following code results in a const eval divide by zero error, when it cannot actually error at runtime:
Bisected to , which corresponds to . cc BTW, you need to actually use (e.g. by calling it in ) to trigger the error. Just adding won't do it.
Fun thing, it doesn't even depend on the conditions in the if clause: also ICEs
Thanks
Change:
<ins> // run-pass use std::ops::Deref; trait MyTrait { fn do_something(&self); fn as_str(&self) -> &str; } impl Deref for dyn MyTrait { type Target = str; fn deref(&self) -> &Self::Target { self.as_str() } } fn trait_object_does_something(t: &dyn MyTrait) { t.do_something() } fn main() {} </ins>

Discussion:
From Code: If the Deref is removed, the code compiles. Presumably, the inclusion of the Deref implementation on the trait object causes the lifetime bounds to change on the do_something method.
Code:
For debugging, notice that is equivalent to .
Triage: still reproduces today.
Triage: still reproduces today.
This no longer reproduces. Tagging as E-needstest
Change:
opts.attrs.push("feature(hella_dope)".to_string()); let expected = "#![feature(sick_rad)] #![feature(hella_dope)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
impl<'tcx> MirPass<'tcx> for Validator { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { let def_id = body.source.def_id(); <del> // We need to param_env_reveal_all_normalized, as some optimizations // change types in ways that require unfolding opaque types. let param_env = tcx.param_env_reveal_all_normalized(def_id); </del> <ins> let param_env = tcx.param_env(def_id); </ins> let mir_phase = self.mir_phase; let always_live_locals = AlwaysLiveLocals::new(body);

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. --I think all of these happen since <!-- 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</detailsThe following samples also did not crash with -Zvalidate-mir with but do crash with  `
cc
Change:
<ins> // Regression test for #74280. #![feature(type_alias_impl_trait)] type Test = impl Copy; fn test() -> Test { let y = || -> Test { () }; //~^ ERROR: concrete type differs from previous defining opaque type use 7 } 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</details
The backtrace suggests that ICE is caused by error formatting machinery. This is a corner case that should be fixed, but my original intention was to provide a concrete type. Sadly, it didn't work out either: results in: Will this be possible one day? My intuition tells me that the snippet above should work. Apologies if this is an improper place for such questions.
The original no longer ICEs since , however the following does Maybe a different ICE?
And the above no longer ICEs since
Change:
// Ignore these errors. } Panic(_) => { <ins> let diagnostic = error_to_const_error(&self.ecx, error); </ins> diagnostic.report_as_lint( self.ecx.tcx, "this expression will panic at runtime",

Discussion:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?