jiebi/CodeConvo huggingface dataset:
Change:
-> Vec<traits::PredicateObligation<'tcx>> { let mut wf = WfPredicates { infcx, param_env, body_id, span, out: vec![] }; <del> wf.compute_trait_ref(trait_ref); </del> <ins> wf.compute_trait_ref(trait_ref, Elaborate::All); </ins> wf.normalize() }

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
/// [pdqsort]: https://github.com/orlp/pdqsort #[stable(feature = "sort_unstable", since = "1.20.0")] #[inline] <del> pub fn sort_unstable_by_key<B, F>(&mut self, f: F) where F: FnMut(&T) -> B, B: Ord </del> <ins> pub fn sort_unstable_by_key<K, F>(&mut self, f: F) where F: FnMut(&T) -> K, K: Ord </ins> { core_slice::SliceExt::sort_unstable_by_key(self, f); }

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<ins> // Regression test for #88684: Improve diagnostics for combining marks // in character literals. // run-rustfix fn main() { let _spade = '♠️'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `♠` is followed by the combining mark `u{fe0f}` //~| HELP: if you meant to write a `str` literal, use double quotes let _s = 'ṩ̂̊'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `s` is followed by the combining marks `u{323}u{307}u{302}u{30a}` //~| HELP: if you meant to write a `str` literal, use double quotes let _a = 'Å'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `A` is followed by the combining mark `u{30a}` //~| HELP: consider using the normalized form `u{c5}` of this character } </ins>

Discussion:
I tried to compile the following code (): For the avoidance of doubt, is . I expected the code to compile—but instead, the literal is rejected: Notably, it is accepted if unicode-escaped: :
The spade "character" in your code is not just a single U+2660, it also has a unicode variation selector U+FE0F: On my machine at least, this makes a visible difference in appearance (which github tries to eliminate by adding a U+FE0F unless I "escape" with a code block):
D'oh! Good spot, thanks Perhaps some improved diagnostics could have helped here?
We have similar diagnostics in other cases of misleading Unicode so that seems like a good idea.
Change:
} TargetOptions Options; <del> Options.NoFramePointerElim = true; </del> <ins> Options.NoFramePointerElim = NoFramePointerElim; </ins> Options.EnableSegmentedStacks = EnableSegmentedStacks; Options.FloatABIType = FloatABI::Default; Options.UseSoftFloat = UseSoftFloat;

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
self.check_defaultness(fi.span, *def); self.check_foreign_fn_bodyless(fi.ident, body.as_deref()); self.check_foreign_fn_headerless(fi.ident, fi.span, sig.header); <ins> self.check_foreign_item_ascii_only(fi.ident); </ins> } ForeignItemKind::TyAlias(box TyAliasKind(def, generics, bounds, body)) => { self.check_defaultness(fi.span, *def); self.check_foreign_kind_bodyless(fi.ident, "type", body.as_ref().map(|b| b.span)); self.check_type_no_bounds(bounds, "`extern` blocks"); self.check_foreign_ty_genericless(generics); <ins> self.check_foreign_item_ascii_only(fi.ident); </ins> } ForeignItemKind::Static(_, _, body) => { self.check_foreign_kind_bodyless(fi.ident, "static", body.as_ref().map(|b| b.span)); <ins> self.check_foreign_item_ascii_only(fi.ident); </ins> } ForeignItemKind::MacCall(..) => {} }

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
Change:
<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>

Discussion:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>

Discussion:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.
Change:
<ins> // check-pass // Allow this for now, can remove this UI test when this becomes a hard error. #![allow(implied_bounds_entailment)] use std::collections::hash_map::{Keys, HashMap}; use std::marker::PhantomData; trait MapAssertion<'a, K, V, R> { fn key_set(&self) -> Subject<Keys<K, V>, (), R>; } struct Subject<'a, T, V, R>(PhantomData<(&'a T, V, R)>); impl<'a, K, V, R> MapAssertion<'a, K, V, R> for Subject<'a, HashMap<K, V>, (), R> { fn key_set(&self) -> Subject<'a, Keys<K, V>, (), R> { todo!() } } 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. --Possibly related to ? in The error message is in building but I can't reproduce with just building that crate, which is odd. <!-- 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 --
label +E-needs-mcve
I'm pretty sure I know how to make an MCVE for this. claim
Ah, lol, it's because hasn't landed, and a recent ReError PR made it delay a bug that should've been handled more gracefully. If you build assertor with (or add ) then it ICEs similarly.
Change:
displayName: Enable IPv6 condition: and(succeeded(), eq(variables['Agent.OS'], 'Linux')) <ins> # Disable automatic line ending conversion (again). On Windows, when we're # installing dependencies, something switches the git configuration directory or # re-enables autocrlf. We've not tracked down the exact cause -- and there may # be multiple -- but this should ensure submodules are checked out with the # appropriate line endings. - bash: git config --replace-all --global core.autocrlf false displayName: "Disable git automatic line ending conversion" </ins> # Check out all our submodules, but more quickly than using git by using one of # our custom scripts - bash: |

Discussion:
Since the change from travis to azure pipelines some of the rust-std archives have DOS line endings in their script, which results in errors like the following when trying to execute: Running works around the issue for now. Not all archives have this issue. Specifically does. Possibly others as well, but our install process fails after the first error, so I am not sure. See mattgodbolt/compiler-explorer-image and mattgodbolt/compiler-explorer-image
Thanks for reporting this! A tentative fix for this landed in , hopefully tomorrow's nightlies will be fixed.
Still happening on :/
Oh, this is concerning, we'll need to look into it a bit more. Thanks for the update. modify labels: regression-from-stable-to-beta -regression-from-stable-to-nightly
May have been actually .. Double checking.
is also affected, does that mean src is now generated from Windows or this is broken even more than it seems?
This is caused by the Azure migration, as it started happening right after we switched nightlies production to it. The initial hypothesis was that git's on Windows was the culprit, but that landed days ago so we need to look deeper :/
The source tarball is generated by all the dist builders and uploaded each time, so the last dist builder to finish will be the one producing the final tarball. I think we see the error there just because our slower builders are all Windows at the moment.
Assigning myself to investigate in the next few days.
Relevant: https://git-
The fix should've landed in today's nightly. Thanks everyone for reporting this!
Just a note, you might want to spin up a beta build as well. was affected by this as well.
yes, beta is still not fixed. The fix was nominated for beta backport though, so once the team approves we will backport it to the beta branch.
We backported the change!
Change:
pub fn tainted_by_errors(error: ErrorGuaranteed) -> ReportedErrorInfo { ReportedErrorInfo { is_tainted_by_errors: true, error } } <ins> pub fn is_tainted_by_errors(&self) -> bool { self.is_tainted_by_errors } </ins> } impl From<ErrorGuaranteed> for ReportedErrorInfo {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
<ins> // Regression test for ICE #125876 fn main() { std::ptr::from_ref(num).cast_mut().as_deref(); //~^ ERROR cannot find value `num` in this scope //~| ERROR no method named `as_deref` found for raw pointer `*mut _` in the current scope //~| WARN type annotations needed //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! //~| WARN type annotations needed //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
<ins> // run-rustfix trait TraitWithAType { type Item: ?Sized; } trait Trait {} struct A {} impl TraitWithAType for A { type Item = dyn Trait; //~ ERROR E0277 } fn main() {} </ins>

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: A similar error message with an unsized generic type argument does mention the implicit bound. Unfortunately, it also doesn't explain the implicit bound up front in the "required by this bound" text. (It mentions it when suggesting to relax the implicit bound, but I think it would be better to mention it up front as well.) Both error messages could benefit from changing the "required by this bound" text to "required by an implicit bound". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-associated-items +A-traits +A-typesystem +D-papercut +D-terse
I'm working on a pull request for this issue. claim
Oh! Very sorry, if you spent too much time on this already, but I have done some work around this already in If you want, you can take over it and bring it to completion, there are some cases, like that still need to be addressed and I haven't yet figured out. Alternatively, if you can find a way to accomplish the same result without touching the and instead deal only with a new , that would be preferable to my approach.
I've pushed what I have so far to , sorry if it conflicts with stuff you've already done. If you'd like to take a look at it, that would be great. I'll take a look at what you have as well. There are some issues to be worked out with conflicting suggestions for associated types for vs the existing suggestion for adding an explicit to a trait's bounds, in test cases such as within a trait declaration.
Change:
fn print_comment(&mut self, cmnt: &comments::Comment) { match cmnt.style { comments::Mixed => { <del> self.zerobreak(); </del> <ins> if !self.is_beginning_of_line() { self.zerobreak(); } </ins> if let Some((last, lines)) = cmnt.lines.split_last() { self.ibox(0);

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
<ins> error[E0382]: use of moved value: `f` --> $DIR/move-error-suggest-clone-panic-issue-127915.rs:10:78 | LL | fn test<T, U>(a: i64, b: i64, c: i64, d: i64, e: i64, f: T, g: U) -> i64 { |                                                       - move occurs because `f` has type `T`, which does not implement the `Copy` trait ... LL |             6, a as f64, b, b as f64, f, c as f64, d, d as f64, e, e as f64, f, g, |                                       - value moved here                     ^ value used here after move | help: if `T` implemented `Clone`, you could clone the value --> $DIR/move-error-suggest-clone-panic-issue-127915.rs:7:9 | LL | fn test<T, U>(a: i64, b: i64, c: i64, d: i64, e: i64, f: T, g: U) -> i64 { |         ^ consider constraining this type parameter with `Clone` ... LL |             6, a as f64, b, b as f64, f, c as f64, d, d as f64, e, e as f64, f, g, |                                       - you could clone this value help: consider restricting type parameter `T` | LL | fn test<T: Copy, U>(a: i64, b: i64, c: i64, d: i64, e: i64, f: T, g: U) -> i64 { |          ++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0382`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
bisects to cc
Thank you. claim