jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: found associated const `BAR` when type was expected --> $DIR/shadowed-const.rs:19:14 | LL |   const QUX: Self::BAR; |              ^^^^^^^^^ error: aborting due to previous error </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. --rust version: (tried in the playground) This compiles successfully on the stable and beta channels. <!-- 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 --
prioritize nightly-to-beta regression
ICE bisected to searched nightlies: from nightly-2021-12-12 to nightly-2022-02-01 regressed nightly: nightly-2022-01-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
I'll take a stab at fixing this, unless (cc: ) wants to! claim feel free to steal this issue from me.
Hmmm actually this might make sense to be a miscompilation now, since it is kind of ambiguous. We probably should default to the old behavior, but not sure if that makes sense goin forward?
So this is two bugs: associated type resolution is ambiguous, because of the conflict between the associated const and the associated type. Probably needs reworking path resolution to prefer types in type position... because only looks for associated types instead of types and consts. I know how to fix (2.), but I'll try to see if I can include something for (1.) as well... Otherwise I'll just put up the one-liner for (2.)

mmm ok this is fair enough, edit: I guess I was just more worried that we'd have to introduce preference for types/consts here which may not have been defined previously
Yeah, my understanding is that types and consts occupy mutually-exclusive positions in well-formed code, but we might not currently have the right information piped into path resolution to prefer resolving one over the other in cases like this. To demonstrate the issue, here is another regression in path resolution, which passes on Stable and fails on Nightly. Not an ICE, but not sure if we should be breaking existing code that compiles. Happy to help work out a fix-forward, or defer that work to you if you're interested in whipping up a fix. Otherwise we might need to roll back (or at least gate its changes to path resolution behind the feature it introduces).
since this only affects nightly, as long as we put in a fix, it should be ok to not rollback, I can try to look into that
Cool! If you're gonna look into it, then I'll give the task to you. release-assignment
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<del> Subproject commit 43495892ded622de51eba7362c5ffae1ed50c9cc </del> <ins> Subproject commit dec0561d198d86a274b1067b53b64fea3c659202 </ins>

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
let param = self.param_at(param.index as usize, tcx); match param.kind { GenericParamDefKind::Const { .. } => param, <del> _ => bug!("expected const parameter, but found another generic parameter"), </del> <ins> _ => bug!("expected const parameter, but found another generic parameter: {param:#?}"), </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' File: --auto-reduced (treereduce-rust): original: Version 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
/// 'ß'.encode_utf8(&mut b); /// ``` #[stable(feature = "unicode_encode_char", since = "1.15.0")] <del> #[rustc_const_unstable(feature = "const_char_encode_utf8", issue = "130512")] </del> <ins> #[rustc_const_stable(feature = "const_char_encode_utf8", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn encode_utf8(self, dst: &mut [u8]) -> &mut str { // SAFETY: `char` is not a surrogate, so this is valid UTF-8. unsafe { from_utf8_unchecked_mut(encode_utf8_raw(self as u32, dst)) }

Discussion:
Feature gate: This is a tracking issue for supporting in const scenarios. [x] Implementation: [x] Address diagnostics: [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge for
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
I'll note that in the , making this const seems to require making the panic error message worse (even in the case where isn't used in a context) and also introducing more uses of . I'm not especially happy about that.
The use of unsafe code cannot be avoided as long as slice indexes aren't const-friendly (AFAIK). But I would argue that this use is properly documented and (relatively) invulnerable to UB, although I am open to other views on this. has also noted that could be used to regain full diagnostics in non-const calls – a feature which I would be more than happy trying to implement.
We could have a safe "const fn subslice" that does the bounds check and then uses unsafe fromrawparts. That would avoid introducing new unsafe reasoning in encode_utf8 itself.
resolves the diagnostics question. Can this be without conflicting with the FCP?
Yeah that should be fine. Thank you! I appreciate that. :-)
Plesse add a FIXME(const-hack) next to the const-eval-select to document that it should be removed again in the future, when possible.
Done. :)
:bell: This is now entering its final comment period, as per the . :bell:
Am I supposed to draft a stabilisation PR or is that outside my domain?
If you want to then yes you can draft a stabilization PR. :) Please link it to this issue and mention that it must only land once FCP has completed.
stabilises this.
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. This will be merged soon.
Change:
<ins> #![feature(staged_api)] #![unstable(feature = "rustc_private", issue = "none")] pub trait MaybeResult<T> {} impl<T> MaybeResult<T> for T {} </ins>

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
self.diverges.set(cond_diverging); }); <ins> if ctxt.may_break { // No way to know whether it's diverging because // of a `break` or an outer `break` or `return`. self.diverges.set(Diverges::Maybe); } </ins> self.tcx.mk_nil() } hir::ExprLoop(ref body, _, source) => {

Discussion:
Having the following main function results in an illigal instruction on stable, beta and nighlty. It should be noted that when is not used after the loop, the illigal instruction does not occur Interestingly putting the same while-loop in a function works fine:
Update: A more simple version that also results in an illigal instruction: after some more trying, it can be shortened to this (and works for functions other than in main, as shown here: ) : adding a statement at the end of main seems to 'fix' the problem
Checking with godbolt, 1.25 and above: results in undefined instruction (this issue) 1.18 to 1.24: ICE with broken MIR 1.17: becomes no-op 1.16 and below: Error "use of undeclared label "
Err the last example is even featured in (introduced in ), but why this seems not tested at all . Edit: It generates an at MIR level. <details<summaryThe initial MIR already contains an unreachable.</summary</details<details<summary-Zunpretty=hir,typed</summary</details
It's because in the example that is tested, there's no semicolon: Why that makes a difference, I haven't determined yet.
The problem is, for some reason, the type checker inferred to have type , and thus the rest of the block is . However, without the the inferred type is just as expected.
Maybe slightly off-topic, but why are references to the label even allowed in the condition, rather than solely the body? You don't achieve extra expressiveness, as it's equivalent to returning false in the condition, and it makes things more complicated.
having code like this results in an ICE:
Because it is consistent with the desugaring of the while loop to a which is a valid and fairly sensible code.
I think the bug in in the type-checker then: it should not be giving the type of , clear. — you interested in fixing? I can give a few tips...
Marking as P-medium: technically a regression, but a very old one, and kind of a corner case. Still, I'll try to leave some notes on how to fix.
yeah, I can have a look into this. Might be a little delayed, but definitely within the next couple of weeks.
Change:
visitor.visit_mir(&mir); for promoted in &mir.promoted { <ins> visitor.mir = promoted; </ins> visitor.visit_mir(promoted); } }

Discussion:
This code produces a compiler error with but compiles successfully with : The error is:
cc
This has to do with how the result of a checked op is a tuple and the 2's complement wrapping value is accessed through : the fix would be to track an initialization with a checked op in a field of , then treat as constant if is promotable and has that flag. I believe that the promoter will work as-is, it's just the constant qualifier that needs to understand this.
Looking at it again, the const qualifier works fine with fields, but the promoter's initial set of potentially promotable temporaries doesn't include the tuple because one of the uses is by-field.
Change:
} if let Some(trait_ref) = trait_ref { <del> push_item_name(tcx, trait_ref.skip_binder().def_id, true, &mut vtable_name); </del> <ins> let trait_ref = tcx.normalize_erasing_late_bound_regions(ty::ParamEnv::reveal_all(), trait_ref); push_item_name(tcx, trait_ref.def_id, true, &mut vtable_name); </ins> visited.clear(); <del> push_generic_params_internal( tcx, trait_ref.skip_binder().substs, &mut vtable_name, &mut visited, ); </del> <ins> push_generic_params_internal(tcx, trait_ref.substs, &mut vtable_name, &mut visited); </ins> } else { vtable_name.push_str("_"); }

Discussion:
Building on Windows ( toolchain) causes an ICE: <details<summarybacktrace</summary</detailsBisecting reveals this was injected by (cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
I'll look into it.
Since landed in 1.57, labeling as stable-to-beta regression.
Re-opening to track the beta backport.
fix backported to beta in PR rollup
Change:
<ins> // Regression test for #121006. //@ revisions: current next //@ ignore-compare-mode-next-solver (explicit revisions) //@[next] compile-flags: -Znext-solver trait ToUnit<'a> { type Unit; } impl<T> ToUnit for T {} //~^ ERROR implicit elided lifetime not allowed here trait Overlap {} impl<U> Overlap for fn(U) {} impl Overlap for for<'a> fn(<() as ToUnit<'a>>::Unit) {} //[current]~^ ERROR the trait bound `for<'a> (): ToUnit<'a>` is not satisfied //[current]~| ERROR the trait bound `for<'a> (): ToUnit<'a>` is not satisfied fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'', 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'' File: --auto-reduced (treereduce-rust): original: Version 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
Regression in nightly-2023-03-22 commit[0] 2023-03-20: Auto merge of - euclio:windows-rs, r=ChrisDenton commit[1] 2023-03-20: Auto merge of - Zoxc:split-execute-job, r=cjgillot,michaelwoerister commit[2] 2023-03-21: Auto merge of - ChrisDenton:libntdll, r=Mark-Simulacrum commit[3] 2023-03-21: Auto merge of - TDecki:dec2flt-inline, r=thomcc commit[4] 2023-03-21: Auto merge of - saethlin:remove-vec-as-ptr-assume, r=thomcc commit[5] 2023-03-21: Auto merge of - Nilstrieb:rollup-seb5xsa, r=Nilstrieb commit[6] 2023-03-21: Auto merge of - ferrocene:pa-test-metrics, r=Mark-Simulacrum commit[7] 2023-03-21: Auto merge of - compiler-errors:local-key, r=cjgillot commit[8] 2023-03-21: Auto merge of - matthiaskrgr:rollup-odn02wu, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days
oh nevermind, still crashes with next-solver-coherence :cryingcatface:
Change:
<ins> #![allow(unused)] fn test_122112() { // Make sure we don't ICE if parsing in recovery fails let _: std::env::temp_dir().join(&self, push: Box<usize>);  //~ ERROR expected one of } </ins> fn main() { let _: std::env::temp_dir().join("foo"); //~ ERROR expected one of }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version 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: --
cc
Change:
<ins> impl Error for str::Utf8Error { //~^ ERROR cannot find trait `Error` in this scope //~| ERROR ambiguous associated type fn description(&self)  {} } 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
I think this is related to
Change:
<ins> trait Trait<const N: Trait = bar> { //~^ ERROR cannot find value `bar` in this scope //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! fn fnc(&self) { } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' File: --auto-reduced (treereduce-rust): original: Version 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.
Change:
<ins> error: unused variable: `var` --> $DIR/issue-117284-arg-in-macro.rs:15:18 | LL |     make_var!(s, var); |                  ^^^ | help: `var` is captured in macro and introduced a unused variable --> $DIR/issue-117284-arg-in-macro.rs:4:13 | LL |         let $var = $struct.$var; |             ^^^^ ... LL |     make_var!(s, var); |     ----------------- in this macro invocation note: the lint level is defined here --> $DIR/issue-117284-arg-in-macro.rs:1:9 | LL | #![deny(unused_variables)] |         ^^^^^^^^^^^^^^^^ = note: this error originates in the macro `make_var` (in Nightly builds, run with -Z macro-backtrace for more info) error: unused variable: `a` --> $DIR/issue-117284-arg-in-macro.rs:16:9 | LL |     let a = 1; |         ^ help: if this is intentional, prefix it with an underscore: `_a` error: aborting due to 2 previous errors </ins>

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
} impl<'g, N:Debug, E:Debug> Iterator for DepthFirstTraversal<'g, N, E> { <del> type Item = &'g N; </del> <ins> type Item = NodeIndex; </ins> <del> fn next(&mut self) -> Option<&'g N> { </del> <ins> fn next(&mut self) -> Option<NodeIndex> { </ins> while let Some(idx) = self.stack.pop() { if !self.visited.insert(idx.node_id()) { continue;

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.