jiebi/CodeConvo huggingface dataset:
Code change:
} fn test_argument_position(x: impl for<'a> Trait<'a, Assoc = impl Copy + 'a>) {} <del> //~^ ERROR `impl Trait` can only mention lifetimes bound at the fn or impl level </del> <ins> //~^ ERROR `impl Trait` can only mention lifetimes from an fn or impl </ins> fn main() {}

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
minimized
Bisected to :sweatsmile:
Code change:
let debugger_visualizers = stat!("debugger-visualizers", || self.encode_debugger_visualizers()); <del> // Encode exported symbols info. This is prefetched in `encode_metadata` so we encode // this as late as possible to give the prefetching as much time as possible to complete. </del> <ins> // Encode exported symbols info. This is prefetched in `encode_metadata`. </ins> let exported_symbols = stat!("exported-symbols", || { self.encode_exported_symbols(tcx.exported_symbols(LOCAL_CRATE)) });

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
another one
Code change:
let debugger_visualizers = stat!("debugger-visualizers", || self.encode_debugger_visualizers()); <del> // Encode exported symbols info. This is prefetched in `encode_metadata` so we encode // this as late as possible to give the prefetching as much time as possible to complete. </del> <ins> // Encode exported symbols info. This is prefetched in `encode_metadata`. </ins> let exported_symbols = stat!("exported-symbols", || { self.encode_exported_symbols(tcx.exported_symbols(LOCAL_CRATE)) });

Related discussion:
text: I just tried out the new parallelization feature of the compiler and it randomly panicked because a deadlock was detected. I tried a couple of times and could not reproduce it unfortunately. : <details<summary<strongBacktrace</strong</summary<p</p</details
Could you provide the minimal example causes the ICE?
The project I compiled was huge and I was not able to consistently reproduce it so reducing my case to a minimal example might take forever. Buy I noticed the issue you linked already contains a fairly small example code so it's probably alright to close my ticket since it seems to be a duplicate of that other ticket anyway.
Can you reproduce this bug using the latest nightly version to get the new error output?
Yes. It appears to be the same issue (albeit while compiling a different dependency but that probably doesn't matter):
BTW with the latest nightly the compiler always and immediately panics and produces multiple back traces. version: nightly-aarch64-apple-darwin unchanged - rustc 1.76.0-nightly ( 2023-12-05) <details<summarycompiler error</summary</details
It would be fixed by
Code change:
let debugger_visualizers = stat!("debugger-visualizers", || self.encode_debugger_visualizers()); <del> // Encode exported symbols info. This is prefetched in `encode_metadata` so we encode // this as late as possible to give the prefetching as much time as possible to complete. </del> <ins> // Encode exported symbols info. This is prefetched in `encode_metadata`. </ins> let exported_symbols = stat!("exported-symbols", || { self.encode_exported_symbols(tcx.exported_symbols(LOCAL_CRATE)) });

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. --I have tried to measure on a 32 core machine and got this ice after several tries. Steps to reproduce: I have got it 2 times in a row, so it should be reproducible. <!-- 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. --:
searched nightlies: from nightly-2023-11-03 to nightly-2023-11-09 regressed nightly: nightly-2023-11-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
modify labels: +A-parallel-queries
modify labels: +WG-compiler-parallel
Can you reproduce this bug using the latest nightly version to get the new error output?
I can build rustc from the sources if you need to check something.
That's all right. It's a same error with other issues
Code change:
<ins> #![feature(optin_builtin_traits)] // Test for issue #56934 - that it is impossible to redundantly // implement an auto-trait for a trait object type that contains it. // Negative impl variant. auto trait Marker1 {} auto trait Marker2 {} trait Object: Marker1 {} // A supertrait marker is illegal... impl !Marker1 for dyn Object + Marker2 { }   //~ ERROR E0371 // ...and also a direct component. impl !Marker2 for dyn Object + Marker2 { }   //~ ERROR E0371 // But implementing a marker if it is not present is OK. impl !Marker2 for dyn Object {} // OK // A non-principal trait-object type is orphan even in its crate. impl !Send for dyn Marker2 {} //~ ERROR E0117 // And impl'ing a remote marker for a local trait object is forbidden // by one of these special orphan-like rules. impl !Send for dyn Object {} //~ ERROR E0321 impl !Send for dyn Object + Marker2 {} //~ ERROR E0321 fn main() { } </ins>

Related discussion:
text: Code gives the same error as , giving (dyn Xyz + Abc + 'static)XyzCode passes coherence, but wfcheck fails because of the confusion:
Code change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StdoutLock<'_> { <ins> self.lock_any() } // Locks this handle with any lifetime. This depends on the // implementation detail that the underlying `ReentrantMutex` is // static. fn lock_any<'a>(&self) -> StdoutLock<'a> { </ins> StdoutLock { inner: self.inner.lock() } } <ins> /// Consumes this handle to the standard output stream, locking the /// shared global buffer associated with the stream and returning a /// writable guard. /// /// The lock is released when the returned lock goes out of scope. The /// returned guard also implements the [`Write`] trait for writing data. /// /// It is often simpler to directly get a locked handle using the /// [`io::stdout_locked`] function instead, unless nearby code also /// needs to use an unlocked handle. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Write}; /// /// fn main() -> io::Result<()> { ///     let mut handle = io::stdout().into_locked(); /// ///     handle.write_all(b"hello world")?; /// ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn into_locked(self) -> StdoutLock<'static> { self.lock_any() } </ins> } #[stable(feature = "std_debug", since = "1.16.0")]

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
Code change:
pub fn print_tts(&mut self, tts: &[ast::TokenTree]) -> IoResult<()> { try!(self.ibox(0)); <ins> let mut suppress_space = false; </ins> for (i, tt) in tts.iter().enumerate() { <del> if i != 0 { </del> <ins> if i != 0 && !suppress_space { </ins> try!(space(&mut self.s)); } try!(self.print_tt(tt)); <ins> // There should be no space between the module name and the following `::` in paths, // otherwise imported macros get re-parsed from crate metadata incorrectly (#20701) suppress_space = match tt { &ast::TtToken(_, token::Ident(_, token::ModName)) | &ast::TtToken(_, token::MatchNt(_, _, _, token::ModName)) | &ast::TtToken(_, token::SubstNt(_, token::ModName)) => true, _ => false } </ins> } self.end() }

Related discussion:
text: Macro definitions encoded to the metadata do not preserve the identifier style, thus certain paths break down.
Nice catch. I was afraid something like this would happen... Really a bug in pretty printing, as it doesn't preserve the ident style. This is what we get for hacking contextual lexer information into the token stream...
The original example now compiles fine, but then I'm not sure about tomaka/android-rs-glue. is this issue still relevant?
I didn't test myself, but reported that it's fixed.
Yeah it looks like this has been fixed, yay!
Code change:
hir_analysis_invalid_union_field_sugg = wrap the field type in `ManuallyDrop<...>` <ins> hir_analysis_late_bound_const_in_apit = `impl Trait` can only mention const parameters from an fn or impl .label = const parameter declared here hir_analysis_late_bound_lifetime_in_apit = `impl Trait` can only mention lifetimes from an fn or impl .label = lifetime declared here hir_analysis_late_bound_type_in_apit = `impl Trait` can only mention type parameters from an fn or impl .label = type parameter declared here </ins> hir_analysis_lifetimes_or_bounds_mismatch_on_trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait

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
minimized
Bisected to :sweatsmile:
Code change:
} key!(is_builtin, bool); <del> key!(endian = "target_endian"); key!(c_int_width = "target_c_int_width"); </del> <ins> key!(endian = "target-endian"); key!(c_int_width = "target-c-int-width"); </ins> key!(os); key!(env); key!(vendor);

Related discussion:
text: Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)
Code change:
LL |     let _: &dyn const Trait; |                 ^^^^^^^^^^^ <del> error: aborting due to 1 previous error </del> <ins> error: `~const` is not allowed here --> $DIR/const-trait-bounds-trait-objects.rs:9:17 | LL |     let _: &dyn ~const Trait; |                 ^^^^^^ | = note: trait objects cannot have `~const` trait bounds error: const trait bounds are not allowed in trait object types --> $DIR/const-trait-bounds-trait-objects.rs:14:25 | LL | const fn handle(_: &dyn const NonConst) {} |                         ^^^^^^^^^^^^^^ error: `~const` is not allowed here --> $DIR/const-trait-bounds-trait-objects.rs:16:23 | LL | const fn take(_: &dyn ~const NonConst) {} |                       ^^^^^^ | = note: trait objects cannot have `~const` trait bounds error: aborting due to 4 previous errors </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [fnsig] computing function signature of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --
bisects to
Code change:
without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_uppercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_uppercase); // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_uppercase); </ins> for c in rest.chars() { match conversions::to_upper(c) {

Related discussion:
text: I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.
Code change:
without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_uppercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_uppercase); // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_uppercase); </ins> for c in rest.chars() { match conversions::to_upper(c) {

Related discussion:
text: The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.
Code change:
t1.next().is_none() && t2.next().is_none() } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenStream) -> bool { let mut t1 = self.trees(); let mut t2 = other.trees(); for (t1, t2) in t1.by_ref().zip(t2.by_ref()) { if !t1.probably_equal_for_proc_macro(&t2) { return false; } } t1.next().is_none() && t2.next().is_none() } </ins> /// Precondition: `self` consists of a single token tree. /// Returns true if the token tree is a joint operation w.r.t. `proc_macro::TokenNode`. pub fn as_tree(self) -> (TokenTree, bool /* joint? */) {

Related discussion:
text: This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.
Code change:
t1.next().is_none() && t2.next().is_none() } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenStream) -> bool { let mut t1 = self.trees(); let mut t2 = other.trees(); for (t1, t2) in t1.by_ref().zip(t2.by_ref()) { if !t1.probably_equal_for_proc_macro(&t2) { return false; } } t1.next().is_none() && t2.next().is_none() } </ins> /// Precondition: `self` consists of a single token tree. /// Returns true if the token tree is a joint operation w.r.t. `proc_macro::TokenNode`. pub fn as_tree(self) -> (TokenTree, bool /* joint? */) {

Related discussion:
text: That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.