jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // compile-flags: -Zsave-analysis // Check that this doesn't ICE when processing associated const (type). fn func() { trait Trait { type MyType; const CONST: Self::MyType = bogus.field; //~ ERROR cannot find value `bogus` } } fn main() {} </ins>

Related discussion:
text: When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?
Code change:
<ins> // compile-flags: -Zsave-analysis // Check that this doesn't ICE when processing associated const (type). fn func() { trait Trait { type MyType; const CONST: Self::MyType = bogus.field; //~ ERROR cannot find value `bogus` } } fn main() {} </ins>

Related discussion:
text: I think this is confirmed by A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting .
Oh, you need to have one table per body: look in HIR for fields and map all of those cases back to the AST. This makes a lot more sense now: so is not wrong, but is looking in the wrong place.
What about this: Seems like we need to before walking the expression of the associated const?
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing segment) but you may be right! Let's see :sweat_smile:
With the fix applied this still ICEs on (this time for type) which means we should nest tables for as well
Code change:
return Ok(()); } <del> let param_env = tcx.param_env(impl_ty.def_id); </del> // Given // // impl<A, B> Foo<u32> for (A, B) {

Related discussion:
text: So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.
Code change:
<del> //@ known-bug: #116308 #![feature(adt_const_params)] pub trait Identity { type Identity; } impl<T> Identity for T { type Identity = Self; } pub fn foo<const X: <i32 as Identity>::Identity>() {} fn main() { foo::<12>(); } </del>

Related discussion:
text: <!-- 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 --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-06-03 Regression in Regression in ?
This is fixed by .
assign
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:panic evaluated #[allow(unused_variables)] fn main() { // This used to trigger an LLVM assertion during compilation let x = [panic!("panic evaluated"); 2]; } </ins>

Related discussion:
text: Currently, will panic, but will not, because the expression is not evaluated in that case.
Also, crashes the compiler. Maybe it's the same issue?
Thanks for the reminder, fixes that as well.
Code change:
[[package]] name = "racer" <del> version = "2.1.48" </del> <ins> version = "2.2.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "7fec2e85e7a30f8fd31b7cf288ad363b5e51fd2cb6f53b416b0cfaabd84e1ccb" </del> <ins> checksum = "b0b4b5faaf07040474e8af74a9e19ff167d5d204df5db5c5c765edecfb900358" </ins> dependencies = [ "bitflags", "clap 2.34.0",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.
Code change:
[[package]] name = "racer" <del> version = "2.1.48" </del> <ins> version = "2.2.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "7fec2e85e7a30f8fd31b7cf288ad363b5e51fd2cb6f53b416b0cfaabd84e1ccb" </del> <ins> checksum = "b0b4b5faaf07040474e8af74a9e19ff167d5d204df5db5c5c765edecfb900358" </ins> dependencies = [ "bitflags", "clap 2.34.0",

Related discussion:
text: One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on
Code change:
impl<'a, 'tcx> Visitor<'tcx> for TypeChecker<'a, 'tcx> { fn visit_local(&mut self, local: &Local, context: PlaceContext, location: Location) { <ins> if self.body.local_decls.get(*local).is_none() { self.fail( location, format!("local {:?} has no corresponding declaration in `body.local_decls`", local), ); } </ins> if self.reachable_blocks.contains(location.block) && context.is_use() { // Uses of locals must occur while the local's storage is allocated. self.storage_liveness.seek_after_primary_effect(location);

Related discussion:
text: When encountering a , there must be a corresponding in the MIR body. If there isn't, later passes can panic due to indexing out of bounds of the array. The validation pass could detect this problem earlier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Instructions: Extend the validation pass in by implementing for the MIR visitor: The trait is documented . The method should check that the local exists in , and fail with a descriptive error message if not (by calling , not by panicking directly).
claim
FYI, the validation pass currently fails on even libcore until is merged, so you need to either wait for that, or cherry-pick some commits from there to get it to work. You can test your changes by running (the validator only runs on very little code by default, turns it on for everything).
I wanted to double check, running should fail when I run it, right? It actually passed for me after I merged in your branch from I wonder if I should try clean and build stage 1 again. :
It should pass with applied, but fail on current master.
So your PR fixes this issue () as well?
Ah, no, this issue is just about adding additional validation. It shouldn't actually detect any locals that don't exist. So the command should work both before and after implementing this. If it fails after implementing this, something else is going on that we should look into.
are you still working on this?
No, sorry. Didn’t have time for it. Go ahead.
release-assignment
Would like to work on this, but it seems there is another check, not on the declaration like this one, but on the memory liveness. This should cover the case that the local is not declared (I think), or would it not?
Code change:
<del> Subproject commit 5d967343acae16fd7b53a61e6cd4e93a1ac6f199 </del> <ins> Subproject commit 569507ef2beefcce4b666af41e09276f06445e96 </ins>

Related discussion:
text: This is intended to be a tracking issue to incorporate into the current beta branch for the Rust 2018 release, as we'll be relying on that in documentation that we're writing.
The Cargo backport is happening here - , and after that needs a PR to the beta branch in this repository
This is now submitted as
Done!
Code change:
<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/missing-lt-outlives-in-rpitit-114274.rs:8:55 | LL |     fn iter(&self) -> impl Iterator<Item = Self::Item<'missing>>; |                                                       ^^^^^^^^ undeclared lifetime | = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html help: consider making the bound lifetime-generic with a new `'missing` lifetime | LL |     fn iter(&self) -> impl for<'missing> Iterator<Item = Self::Item<'missing>>; |                            +++++++++++++ help: consider introducing lifetime `'missing` here | LL |     fn iter<'missing>(&self) -> impl Iterator<Item = Self::Item<'missing>>; |            ++++++++++ help: consider introducing lifetime `'missing` here | LL | trait Iterable<'missing> { |               ++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0261`. </ins>

Related discussion:
text: <!-- 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
Code change:
| PathSource::Struct | PathSource::TupleStruct(..) => false, }; <del> let mut error = false; </del> <ins> let mut res = LifetimeRes::Error; </ins> for rib in self.lifetime_ribs.iter().rev() { match rib.kind { // In create-parameter mode we error here because we don't want to support

Related discussion:
text: I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.
Code change:
<ins> // revisions: imported unimported //[imported] check-pass </ins> mod private { pub trait Future { <ins> //[unimported]~^^ HELP perhaps add a `use` for it </ins> fn wait(&self) where Self: Sized; }

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.
Code change:
<ins> // revisions: imported unimported //[imported] check-pass </ins> mod private { pub trait Future { <ins> //[unimported]~^^ HELP perhaps add a `use` for it </ins> fn wait(&self) where Self: Sized; }

Related discussion:
text: (cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.
Code change:
{ // When the suggested binding change would be from `x` to `_x`, suggest changing the // original binding definition instead. (#60164) <del> (span, snippet, ", consider changing it") </del> <ins> let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) </ins> } else { <del> (span, suggestion.candidate.to_string(), "") </del> <ins> (span, suggestion.candidate.to_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(

Related discussion:
text: I tried on Rust 1.76.0: I got the following error: Note that the suggestion has stripped the leading character from the enum's name.
Can confirm this is still present in nightly.
Sounds like fun. Taking a look.
So it is intended this way from what I can see in the source code: Improving the wording would be become to clear the confusion though I think.
Code change:
<ins> error: this operation will panic at runtime --> $DIR/unconditional_panic_98444.rs:6:13 | LL |     let _ = xs[7]; |             ^^^^^ index out of bounds: the length is 5 but the index is 7 | = note: `#[deny(unconditional_panic)]` on by default error: aborting due to previous error </ins>

Related discussion:
text: <!-- 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 this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Code change:
<ins> // run-pass // Makes sure we don't propagate generic instances of `Self: ?Sized` blanket impls. // This is relevant when we have an overlapping impl and builtin dyn instance. // See <https://github.com/rust-lang/rust/pull/114941> for more context. trait Trait { fn foo(&self) -> &'static str; } impl<T: ?Sized> Trait for T { fn foo(&self) -> &'static str { std::any::type_name::<T>() } } const fn bar<T: ?Sized>() -> fn(&T) -> &'static str { Trait::foo // If const prop were to propagate the instance } fn main() { assert_eq!("i32", bar::<dyn Trait>()(&1i32)); } </ins>

Related discussion:
text: <!-- 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 this happen: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high