jiebi/CodeConvo huggingface dataset:
Change:
bb0: { StorageLive(_1);                 // scope 0 at $DIR/const_prop_miscompile.rs:+1:9: +1:14 <del> -         _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 +         _1 = const (1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </del> <ins> _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </ins> StorageLive(_2);                 // scope 1 at $DIR/const_prop_miscompile.rs:+2:5: +4:6 StorageLive(_3);                 // scope 2 at $DIR/const_prop_miscompile.rs:+3:10: +3:22 _3 = &raw mut (_1.0: i32);       // scope 2 at $DIR/const_prop_miscompile.rs:+3:10: +3:22

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/111189>. // This test ensures that it doesn't crash. #![deny(warnings)] /// #[rustfmt::skip] //~^ ERROR unresolved link to `rustfmt::skip` /// #[clippy::whatever] //~^ ERROR unresolved link to `clippy::whatever` pub fn foo() {} </ins>

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
return; } if self.glob_map.contains_key(&import_id) { <del> self.glob_map[import_id].insert(name); </del> <ins> self.glob_map.get_mut(&import_id).unwrap().insert(name); </ins> return; }

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
<ins> error[E0061]: this function takes 1 argument but 2 arguments were supplied --> $DIR/wrong_argument_ice-3.rs:9:16 | LL |         groups.push(new_group, vec![process]); |                ^^^^ ---------  ------------- supplied 2 arguments |                | |                expected 1 argument | note: associated function defined here --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL | LL |     pub fn push(&mut self, value: T) { |            ^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </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. --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. --: <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim
Change:
<ins> // Checks that const parameters cannot be shadowed with fresh bindings // even in syntactically unambiguous contexts. See // https://github.com/rust-lang/rust/issues/33118#issuecomment-233962221 fn foo<const N: i32>(i: i32) -> bool { match i { N @ _ => true, //~^ ERROR: match bindings cannot shadow const parameters [E0530] } } fn bar<const N: i32>(i: i32) -> bool { let N @ _ = 0; //~^ ERROR: let bindings cannot shadow const parameters [E0530] match i { N @ _ => true, } } 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
args.extend(vec!["--sysroot".into(), sys_root]); }; <del> return rustc_driver::run_compiler(&args, &mut DefaultCallbacks, None, None, None); </del> <ins> return rustc_driver::RunCompiler::new(&args, &mut DefaultCallbacks).run(); </ins> } if orig_args.iter().any(|a| a == "--version" || a == "-V") {

Discussion:
This argument list is slowly getting out of hand. Maybe we should create a builder pattern struct that doesn't require most calls to use ? Anyway, pre-existing, if you rather open an issue about it than fix it here, I'm fine with merging this PR Originally posted by in
modify labels: +A-driver +C-cleanup +T-compiler
I would like to give this a try if mentoring is available
I'll be happy to mentor, but we should wait for to get merged, because any change you do will conflict with that PR. Though you can start by basing your change on top of that PR. You will need to modify each place that is modified in that PR, so keep it bookmarked and look at it whenever you end up wondering what you may need to touch. The root change to do is to make private and add a new struct right next to it. That new struct should have a field for every parameter of the function and an inherent method () that just forwards all these fields to . You'll need a method that takes only the non- fields as parameters and creates a new instance of your builder struct with those fileds initialized and the rest set to . Then you'll need a method for each field to be able to set it. After adjusting all the callsites and everything compiles again, you should make a commit and put all follow-up changes in separate commits. As a follow up change you can make take the struct as an argument instead of all the fields individually. You can then destructure the struct in the body of to get all the fields out. There may be other things that you may notice while implementing this change that could be optimized, idk, but we can close this issue after the above changes.
Hi I was trying to get my hands on this. But since Optional fields can't be copied to runcompile, how can I pass those fields to ?. Here is code change that you suggested. I could technically replace to accept references instead of values but that will require the entire function to refactor, and I am not sure I can do that. Am I doing it wrong? What alternative I can take to get this issue fixed?
can take instead of .
Thanks just been away from rust for like 15 days and completely forgot I can do that. one more thing. was also used in miri and rls submodules.

Do I need to make a pull request there for the changes. Thanks.
Once (beta branching) is merged it is fine for miri and rls to break. Submitting a PR there is nice, but not necessary. The respective maintainers are normally the ones to fix them again.
Change:
<ins> macro_rules! m { ($s:stmt) => {} } m! { mut x } //~^ ERROR expected expression, found keyword `mut` //~| ERROR expected a statement m! { auto x } //~^ ERROR invalid variable declaration m! { var x } //~^ ERROR invalid variable declaration fn main() {} </ins>

Discussion:
<!-- 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<summary<strongBacktrace</strong</summary<p</p</details label A-parser A-macros <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc this should probably be gated with your "may eagerly recover" work as well
This code is actually already mentioned in ;)
claim
Yeah, gating this recovery behind a is the correct fix here.
Also very fun that these things can ICE sometimes.
Found these also panic: Since these are highly related to the case, one pull request can fix all of these (maybe).
Change:
} } <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> impl<'a, I, T: 'a> ExactSizeIterator for Copied<I> where I: ExactSizeIterator<Item=&'a T>, T: Copy {

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn max_by_key<T, F: FnMut(&T) -> K, K: Ord>(v1: T, v2: T, mut f: F) -> T { max_by(v1, v2, |v1, v2| f(v1).cmp(&f(v2))) }

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
return; }; // Get the span of the generics args *including* the leading `::`. <del> let args_span = assoc_segment.ident.span.shrink_to_hi().to(args.span_ext); </del> <ins> // We do so by stretching args.span_ext to the left by 2. Earlier // it was done based on the end of assoc segment but that sometimes // led to impossible spans and caused issues like #116473 let args_span = args.span_ext.with_lo(args.span_ext.lo() - BytePos(2)); </ins> if tcx.generics_of(adt_def.did()).count() == 0 { // FIXME(estebank): we could also verify that the arguments being // work for the `enum`, instead of just looking if it takes *any*.

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the problem is probably line 8 of the suggestion? !
claim
Minimized a bit more: The issue occurs because we compute a wrong span for the args . Instead of this: it spans the entire distance from the end of in the first line to the end of in the next line: The reasons for this is that we compute the span starting from the end of the variant path segment ( in this case) to end of the args (the right angle bracket of of ). Normally it works, but leads to the above miscalculation when the variant and the args reside in different macros or expansions as in the present case. The offending source code doing the span computation is this:
Change:
// though we can easily give a hint that ought to be // relevant. err.note( <del> "lifetimes appearing in an associated type are not considered constrained", </del> <ins> "lifetimes appearing in an associated or opaque type are not considered constrained", </ins> ); <ins> err.note("consider introducing a named lifetime parameter"); </ins> } err.emit();

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/15.0-2022-08-09 </del> <ins> branch = rustc/15.0-2022-12-07 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

Discussion:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:

<!-- 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 found this issue when I was compiling one of my large projects, and was able to track it down to the code below. Unfortunately, I haven't been able to reproduce the issue on any other machines other than this one (which is running Ubuntu 20.02.4 on Oracle Cloud, if that matters). The error only seems to happen in release mode in nightly. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
label +A-LLVM
I can reproduce this via .
Reduced:
Upstream issue:
Change:
// except according to those terms. macro_rules! invalid { <del> _ => (); //~^ ERROR Invalid macro matcher </del> <ins> _ => (); //~^ ERROR invalid macro matcher </ins> } fn main() {

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
<ins> // check-pass fn f<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } 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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
#![deny(let_underscore_drop)] fn main() { <del> let _ = foo(); //~ ERROR non-binding let on a type that implements `Drop` </del> <ins> let _ = foo(); //~ ERROR non-binding let on a type that has a destructor </ins> } async fn from_config(_: Config) {}

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
<ins> // This test ensures that the same implementation doesn't show more than once. // It's a regression test for https://github.com/rust-lang/rust/issues/96036. #![crate_name = "foo"] // We check that there is only one "impl<T> Something<Whatever> for T" listed in the // blanket implementations. // @has 'foo/struct.Whatever.html' // @count - '//*[@id="blanket-implementations-list"]/section[@class="impl has-srclink"]' 1 pub trait Something<T> { } pub struct Whatever; impl<T> Something<Whatever> for T {} </ins>

Discussion:
! All pointing to the same impl: ! label +T-rustdoc
Actually, the never type , the trait and are not needed: It occurs with any type and any parameterized trait. Minimal reproducible example: The number of duplicates depends on the number of public types accessible in the target crate.
Taking a look.
code: Gives: !