jiebi/CodeConvo huggingface dataset:
Change:
fn main () { let foo = 42u32; let _: [u8; foo]; //~ ERROR E0435 <del> //~| NOTE non-constant used with constant </del> <ins> //~| NOTE non-constant value </ins> }

Discussion:
rustc 1.0.0 - 1.11.0: rustc 1.12.0 - 1.15.0: rustc 1.16.0 - present: Can we have the first one back please?
To clarify, the problem is in the note:
Note introduced in , using the exact wording from . Rust 1.12 fully transitioned to MIR, which made the repeat count no longer special, thus losing the special error message. I think the note should be reworded to "non-constant used as constant".
The error message today speaks the truth and does so quite well. Closing.
The span label is still pretty nonsensical.
Okay, I'll reopen. Can you provide the exact wording you'd expect? (I personally don't really see any point for a span label, but ... ).
Either remove the label or just "non-constant value" seems to make more sense to me. It's the "with constant" that is weird IMO.
I'll PR.
I just came here after googling and want to say that the first error message is a lot easier to understand!
Change:
#![feature(concat_idents)] #![feature(const_cstr_unchecked)] #![feature(const_fn_floating_point_arithmetic)] <del> #![feature(const_fn_transmute)] </del> #![feature(const_fn_fn_ptr_basics)] <ins> #![feature(const_fn_transmute)] </ins> #![feature(const_io_structs)] #![feature(const_ip)] <ins> #![feature(const_ipv4)] </ins> #![feature(const_ipv6)] #![feature(const_raw_ptr_deref)] #![feature(const_socketaddr)] <del> #![feature(const_ipv4)] </del> #![feature(container_error_extra)] #![feature(core_intrinsics)] #![feature(custom_test_frameworks)]

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
} // @has manual_impl/struct.S3.html '//*[@class="trait"]' 'T' <del> // @has  - '//details[@open=""]/div[@class="docblock"]' 'Docs associated with the S3 trait implementation.' </del> <ins> // @has  - '//details/div[@class="docblock"]' 'Docs associated with the S3 trait implementation.' // @!has  - '//details[@open=""]/div[@class="docblock"]' 'Docs associated with the S3 trait implementation.' </ins> // @has  - '//details[@open=""]/div[@class="docblock"]' 'Docs associated with the S3 trait b_method implementation.' // @!has - '//div[@class="impl-items"]/details[@open=""]//div[@class="docblock"]' 'Docs associated with the trait a_method definition.' // @has - '//div[@class="impl-items"]/details//div[@class="docblock"]' 'Docs associated with the trait a_method definition.'

Discussion:
beta and nightly ignore the default-on configuration of "Auto-hide trait implementation documentation" On stable  looks like: ! While it looks like: ! And (as of 2021-05-17): ! Going to and toggling "Auto-hide trait implementation documentation" off makes stable look the same as beta, so it definitely seems like beta/nightly are just ignoring this toggle.
This is due to the refactoring we've been doing with the expand / collapse toggles, wrapping them in tags. The code that expands and collapses them based on settings is here: You can see there's an entry for handling "implementors" but not one for "implementations." Right now, both implementors and implementations get wrapped in a tag with . We need to update this Rust code: So that it generates for implementors and for implementations. And then update the JS to add a clause for implementations.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I'm having trouble figuring out what fields to check in to figure out if we're rendering an implementor or an implementation. If someone's able to point me in the right direction I'd appreciate it!
Well, I think I handled it in (funny that I was noticed it and fixed it on my side and someone else find it out too).
Change:
<ins> // Copyright 2017 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. fn main() { let value = 1; match SomeStruct(value) { StructConst1(_) => { }, //~^ ERROR expected tuple struct/variant, found constant `StructConst1` _ => { }, } struct SomeStruct(u8); const StructConst1 : SomeStruct = SomeStruct(1); const StructConst2 : SomeStruct = SomeStruct(2); } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
use rustc_trait_selection::traits::query::type_op::{self, TypeOpOutput}; use rustc_trait_selection::traits::ObligationCause; <del> use crate::diagnostics::{ToUniverseInfo, UniverseInfo}; </del> <ins> use crate::diagnostics::ToUniverseInfo; </ins> use super::{Locations, NormalizeLocation, TypeChecker};

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. --Does not happen with this callback: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
The code snippet is incomplete: is there a repository available that we could try, to reproduce the error? If not, could you at least add the full function? Thanks!
Rust use tungstenite::handshake::server::{Response, ErrorResponse}; fn acceptconnection(stream: TcpStream, config: rustls::server::ServerConfig) -Result<Socket{ let mut conn = rustls::server::ServerConnection::new(std::sync::Arc::new(()))?; let tlsstream = rustls::StreamOwned::new(conn, stream.tryclone()?); if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, -std::result::Result<Response, ErrorResponse{ let callback = -std::result::Result<tungstenite::handshake::server::Response, tungstenite::handshake::server::ErrorResponse{ dbg!(&req); dbg!(&res); Ok(res) }; if let Ok(ws) = match tungstenite::accepthdrwithconfig(tlsstream, callback, None) { Err(HandshakeError::Interrupted(midhandshake)) ={ info!( "Handshake interrupted with peer {} - waiting to try again.", peer_addr ); Ok(Socket::Interrupted(midhandshake)) } Err(e) ={ error!("Error accepting secure websocket connection: {e}"); Err(e)? } Ok(ws) =Ok(Socket::SecureWebSocket(ws)), } } }
This is still incomplete and doesn't parse. Do you have a repository where the issue can be reproduced?
No repo. You can make it parse pretty easily. I am not a rustc expert but I believe the issue was with the callback.
Here's a small (but not minimal yet) working repro: and with that we can finally bisect, to : probably that (no need to ping anyone here) I'll minimize next to remove this dependency and create an MCVE.
removed:
Probably not yet an MCVE and could be further simplified, but getting close.

62 error -1.63 error + ice
WG-prioritization assigning priority (). label -I-prioritize +P-medium -E-needs-mcve
Change:
var aliases = []; var crateAliases = []; var i; <del> if (filterCrates !== undefined && ALIASES[filterCrates] && ALIASES[filterCrates][query.search]) { for (i = 0; i < ALIASES[crate][query.search].length; ++i) { aliases.push( createAliasFromItem(searchIndex[ALIASES[filterCrates][query.search]])); </del> <ins> if (filterCrates !== undefined) { if (ALIASES[filterCrates] && ALIASES[filterCrates][query.search]) { for (i = 0; i < ALIASES[filterCrates][query.search].length; ++i) { aliases.push( createAliasFromItem( searchIndex[ALIASES[filterCrates][query.search][i]])); } </ins> } } else { Object.keys(ALIASES).forEach(function(crate) {

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
<ins> // ignore-tidy-linelength #![deny(warnings)] struct Borked {} impl Borked { fn a(&self) {} } fn run_wild<T>(b: &Borked) { b.a::<'_, T>(); //~^ ERROR cannot specify lifetime arguments explicitly if late bound lifetime parameters are present //~^^ ERROR wrong number of type arguments: expected 0, found 1 //~^^^ WARN this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! } fn main() {} </ins>

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
fn from_str(link: &str) -> Result<Option<(Self, &str, &str)>, (String, Range<usize>)> { use Disambiguator::{Kind, Namespace as NS, Primitive}; <ins> let suffixes = [ // If you update this list, please also update the relevant rustdoc book section! ("!()", DefKind::Macro(MacroKind::Bang)), ("!{}", DefKind::Macro(MacroKind::Bang)), ("![]", DefKind::Macro(MacroKind::Bang)), ("()", DefKind::Fn), ("!", DefKind::Macro(MacroKind::Bang)), ]; </ins> if let Some(idx) = link.find('@') { let (prefix, rest) = link.split_at(idx); let d = match prefix {

Discussion:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Occurs on stable + nightly : : i replaced backtrace with for readability since it's displayed without any flags: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The combination of course seems invalid, but the compiler shouldn't panic, right?
That was quick, thank you!
Change:
<ins> #![recursion_limit = "5"] // To reduce noise //expect incompatible type error when ambiguous traits are in scope //and not an overflow error on the span in the main function. struct Ratio<T>(T); pub trait Pow { fn pow(self) -> Self; } impl<'a, T> Pow for &'a Ratio<T> where &'a T: Pow, { fn pow(self) -> Self { self } } fn downcast<'a, W: ?Sized>() -> std::io::Result<&'a W> { todo!() } struct Other; fn main() -> std::io::Result<()> { let other: Other = downcast()?;//~ERROR 28:24: 28:35: `?` operator has incompatible types Ok(()) } </ins>

Discussion:
: and then if I increase the recursion limit enough... adding a backtrace gives nothing new, however, compiling on nightly gives the following: </p</detailsI strongly suspect this is related to , but that issue is now old and should have been solved. Perhaps a regression?
can you provide the you compiled that code snippet with? The provided code doesn't seem complete.
I can reproduce it with in the section of a , but this is not an ICE.
Change:
<ins> // test for ice #109178  cannot relate region: LUB(ReErased, ReError) #![allow(incomplete_features)] #![crate_type = "lib"] #![feature(adt_const_params, generic_const_exprs)] struct Changes<const CHANGES: &[&'static str]> //~^ ERROR `&` without an explicit lifetime name cannot be used here where [(); CHANGES.len()]:, {} impl<const CHANGES: &[&str]> Changes<CHANGES> where [(); CHANGES.len()]: {} //~^ ERROR `&` without an explicit lifetime name cannot be used here //~^^ ERROR `&` without an explicit lifetime name cannot be used here </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
searched toolchains through Regression in
label +S-bug-has-mcve
Triage: the ICE has been fixed since nightly-2023-05-17. labels: +E-needs-test
Change:
// except according to those terms. impl (u8, u8) { //~ ERROR E0118 <ins> //~^ NOTE impl requires a base type //~| NOTE either implement a trait on it or create a newtype to wrap it instead </ins> fn get_state(&self) -> String { String::new() }

Discussion:
From: src/test/compile- Error E0118 needs a spanlabel and a spannote to be a simple note, updating from: To: Bonus: It'd be good if we could underline the type it's complaining about.
In case no one is working with this yet, I can give this a go.

From: src/test/compile- Error E0117 needs a span_label, updated error text, and a note, updating it from: to:
In case no one is working with this yet, I can give this a go.
Change:
#![feature(pattern)] #![feature(placement_in_syntax)] #![feature(rand)] <ins> #![feature(slice_sort_by_cached_key)] </ins> #![feature(splice)] #![feature(str_escape)] #![feature(string_retain)]

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:
bx.store(place.llval, alloca.llval, alloca.align); // Point the debug info to `*alloca` for the current variable <del> bx.dbg_var_addr(dbg_var, dbg_loc, alloca.llval, Size::ZERO, &[Size::ZERO], None); </del> <ins> bx.dbg_var_addr( dbg_var, dbg_loc, alloca.llval, Size::ZERO, &[Size::ZERO], var.fragment, ); </ins> } else { <del> bx.dbg_var_addr(dbg_var, dbg_loc, base.llval, direct_offset, &indirect_offsets, None); </del> <ins> bx.dbg_var_addr( dbg_var, dbg_loc, base.llval, direct_offset, &indirect_offsets, var.fragment, ); </ins> } }

Discussion:
Building Firefox for the thumbv7neon-linux-androideabi and i686-linux-android fails with a rust compiler crash: I wish I could give something more detailed, but I haven't had the time to try to yet. I however identified the regression to come from (Enable ScalarReplacementOfAggregates in optimized builds) and building with avoids the crash.
Duplicate of
going to close as such. thanks for reporting !
Change:
<ins> // Regression test for issue #57807 - ensure // that we properly unify associated types within // a type alias impl trait // check-pass #![feature(type_alias_impl_trait)] trait Bar { type A; } impl Bar for () { type A = (); } trait Foo { type A; type B: Bar<A = Self::A>; fn foo() -> Self::B; } impl Foo for () { type A = (); type B = impl Bar<A = Self::A>; fn foo() -> Self::B { () } } fn main() {} </ins>

Discussion:
The following code fails to compile (): with the following error If you make this modification, it compiles fine:
I think maybe cc or ?
I wonder whether this is a dupe of ?

Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.
Change:
// ever used for a comparison against the capture tokenstream. let source = pprust::nonterminal_to_string_no_extra_parens(nt); let filename = FileName::macro_expansion_source_code(&source); <del> let reparsed_tokens = parse_stream_from_source_str(filename, source, sess, Some(span)); </del> <ins> let reparsed_tokens = parse_stream_from_source_str(filename, source.clone(), sess, Some(span)); </ins> // During early phases of the compiler the AST could get modified // directly (e.g., attributes added or removed) and the internal cache

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
<ins> #![crate_name = "foo"] #![feature(doc_cfg)] #![feature(staged_api)] #![stable(feature = "rust1", since = "1.0.0")] #[stable(feature = "rust1", since = "1.0.0")] pub mod tag { #[unstable(feature = "humans", issue = "none")] pub trait Unstable {} #[stable(feature = "rust1", since = "1.0.0")] #[doc(cfg(feature = "sync"))] pub trait Portability {} #[unstable(feature = "humans", issue = "none")] #[doc(cfg(feature = "sync"))] pub trait Both {} #[stable(feature = "rust1", since = "1.0.0")] pub trait None {} } // @has foo/mod1/index.html #[stable(feature = "rust1", since = "1.0.0")] pub mod mod1 { // @has - '//code' 'pub use tag::Unstable;' // @has - '//span' 'Experimental' // @!has - '//span' 'sync' #[stable(feature = "rust1", since = "1.0.0")] pub use tag::Unstable; } // @has foo/mod2/index.html #[stable(feature = "rust1", since = "1.0.0")] pub mod mod2 { // @has - '//code' 'pub use tag::Portability;' // @!has - '//span' 'Experimental' // @has - '//span' 'sync' #[stable(feature = "rust1", since = "1.0.0")] pub use tag::Portability; } // @has foo/mod3/index.html #[stable(feature = "rust1", since = "1.0.0")] pub mod mod3 { // @has - '//code' 'pub use tag::Both;' // @has - '//span' 'Experimental' // @has - '//span' 'sync' #[stable(feature = "rust1", since = "1.0.0")] pub use tag::Both; } // @has foo/mod4/index.html #[stable(feature = "rust1", since = "1.0.0")] pub mod mod4 { // @has - '//code' 'pub use tag::None;' // @!has - '//span' 'Experimental' // @!has - '//span' 'sync' #[stable(feature = "rust1", since = "1.0.0")] pub use tag::None; } </ins>

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim