jiebi/CodeConvo huggingface dataset:
Change:
<del> //@ known-bug: #116721 //@ compile-flags: -Zmir-opt-level=3 --emit=mir fn hey<T>(it: &[T]) where [T]: Clone, { } fn main() {} </del>

Discussion:
File: season two 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
<ins> // Copyright 2016 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() { match (0, 0) { (std::usize::MIN, std::usize::MAX) => {} _ => {} } } </ins>

Discussion:
My bad, there's a temporary that ended up in a discriminant. Minimal testcase: The can be fixed by pulling it out into a variable, .
Change:
<ins> //@ compile-flags:--test --test-args=--test-threads=1 //@ normalize-stdout-test: "tests/rustdoc-ui/doctest" -> "$$DIR" //@ normalize-stdout-test: "finished in d+.d+s" -> "finished in $$TIME" //@ failure-status: 101 // https://github.com/rust-lang/rust/issues/130470 #![doc = include_str!("doctest-output-include-fail.md")] </ins>

Discussion:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.
Change:
<ins> #![feature(associated_type_bounds)] // Test for <https://github.com/rust-lang/rust/issues/119857>. pub trait Iter { type Item<'a>: 'a where Self: 'a; fn next<'a>(&'a mut self) -> Option<Self::Item<'a, As1: Copy>>; //~^ ERROR associated type bindings are not allowed here } impl Iter for () { type Item<'a> = &'a mut [()]; fn next<'a>(&'a mut self) -> Option<Self::Item<'a>> { None } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details

<!-- 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
Regression in nightly-2023-05-04 commit[0] 2023-05-02: Auto merge of - compiler-errors:attr-query-no-caching, r=cjgillot commit[1] 2023-05-02: Auto merge of - fortanix:raoul/bugfixlibtestjson_synchronization, r=pietroalbini commit[2] 2023-05-03: Auto merge of - nnethercote:restrict-From-for-Diagnostics, r=davidtwco commit[3] 2023-05-03: Auto merge of - weihanglo:update-cargo, r=weihanglo commit[4] 2023-05-03: Auto merge of - jdno:reduce-builder-sizes, r=pietroalbini commit[5] 2023-05-03: Auto merge of - cuviper:ct-ng-1.25, r=pietroalbini commit[6] 2023-05-03: Auto merge of - Dylan-DPC:rollup-0pq0hh3, r=Dylan-DPC
Minimized:
Above example bisects to :thinking:
Change:
[72062]: https://github.com/rust-lang/rust/pull/72062/ [72094]: https://github.com/rust-lang/rust/pull/72094/ [72133]: https://github.com/rust-lang/rust/pull/72133/ <ins> [67759]: https://github.com/rust-lang/rust/pull/67759/ </ins> [71900]: https://github.com/rust-lang/rust/pull/71900/ [71928]: https://github.com/rust-lang/rust/pull/71928/ [71662]: https://github.com/rust-lang/rust/pull/71662/

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
self.handle_term(ct, ty::Const::outer_exclusive_binder, |tcx, guar| { ty::Const::new_error(tcx, guar, ct.ty()) }) <ins> .super_fold_with(self) </ins> } fn fold_predicate(&mut self, predicate: ty::Predicate<'tcx>) -> ty::Predicate<'tcx> {

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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: option is to avoid error message (there exists another error at the end of the backtrace) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: Might be related to unsolved ICE Issue- (issue fixed by adding test-case), where the issue points to
Change:
let x: Box<ManuallyDrop<[TypeWithDrop]>> = Box::new(ManuallyDrop::new([TypeWithDrop, TypeWithDrop])); drop(x); <ins> // test clone and clone_from implementations let mut x = ManuallyDrop::new(TypeWithDrop); let y = x.clone(); x.clone_from(&y); drop(x); drop(y); </ins> }

Discussion:
With on , will not drop the inside , just like does not drop the original before overwriting it. However, a manual implementation of can only make use of the efficiency of a overriden on (e.g. memory reuse by a ) by simply forwarding to it, which means that will not forget the old value. This new (forwarding, so (potentially) dropping) behaviour was in , and (for now) reverted in So question for What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.
I feel that the old behavior is correct (not calling drop). should behave like which for means not dropping the old value. I don't think there is much loss of efficiency in practice: use of is already pretty rare and I don't think there are any cases of it being used with .
Sounds good. Closing this.
No wait, we still need to do this part. :)
Change:
return Err(err); } <del> Ok(Assert { cond_expr: parser.parse_expr()?, custom_message: if parser.eat(&token::Comma) { let ts = parser.parse_tokens(); if !ts.is_empty() { Some(ts) } else { None } } else { None }, }) </del> <ins> let cond_expr = parser.parse_expr()?; // Some crates use the `assert!` macro in the following form (note extra semicolon): // // assert!( //     my_function(); // ); // // Warn about semicolon and suggest removing it. Eventually, this should be turned into an // error. if parser.token == token::Semi { let mut err = cx.struct_span_warn(sp, "macro requires an expression as an argument"); err.span_suggestion( parser.span, "try removing semicolon", String::new(), Applicability::MaybeIncorrect ); err.note("this is going to be an error in the future"); err.emit(); parser.bump(); } // Some crates use the `assert!` macro in the following form (note missing comma before // message): // // assert!(true "error message"); // // Parse this as an actual message, and suggest inserting a comma. Eventually, this should be // turned into an error. let custom_message = if let token::Literal(token::Lit::Str_(_), _) = parser.token { let mut err = cx.struct_span_warn(parser.span, "unexpected string literal"); let comma_span = cx.source_map().next_point(parser.prev_span); err.span_suggestion_short( comma_span, "try adding a comma", ", ".to_string(), Applicability::MaybeIncorrect ); err.note("this is going to be an error in the future"); err.emit(); parse_custom_message(&mut parser) } else if parser.eat(&token::Comma) { parse_custom_message(&mut parser) } else { None }; if parser.token != token::Eof { parser.expect_one_of(&[], &[])?; unreachable!(); } Ok(Assert { cond_expr, custom_message }) } fn parse_custom_message<'a>(parser: &mut Parser<'a>) -> Option<TokenStream> { let ts = parser.parse_tokens(); if !ts.is_empty() { Some(ts) } else { None } </ins> }

Discussion:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.
Change:
let generate_link_to_definition = matches.opt_present("generate-link-to-definition"); let extern_html_root_takes_precedence = matches.opt_present("extern-html-root-takes-precedence"); <ins> let html_no_source = matches.opt_present("html-no-source"); </ins> if generate_link_to_definition && (show_coverage || output_format != OutputFormat::Html) { diag.struct_err(

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
} ty::TyTrait(box ty::TraitTy { ref principal, ref bounds }) => { let did = principal.def_id(); <del> let fqn = cx.tcx().sess.cstore.item_path(did); let fqn: Vec<_> = fqn.into_iter().map(|i| i.to_string()).collect(); </del> <ins> inline::record_extern_fqn(cx, did, TypeTrait); </ins> let (typarams, bindings) = bounds.clean(cx); <del> let path = external_path(cx, &fqn.last().unwrap().to_string(), </del> <ins> let path = external_path(cx, &cx.tcx().item_name(did).as_str(), </ins> Some(did), bindings, principal.substs()); <del> cx.external_paths.borrow_mut().as_mut().unwrap().insert(did, (fqn, TypeTrait)); </del> ResolvedPath { path: path, typarams: Some(typarams),

Discussion:
The [src] link on these pages is broken: The links are also broken in the stable docs version of these pages.
I think this should be fixed by . The links wrongly point to instead of because the crate is linked in std like
I've built the docs locally and the issue somehow persists.
Change:
#[must_use = "use `.truncate()` if you don't need the other half"] #[stable(feature = "split_off", since = "1.4.0")] pub fn split_off(&mut self, at: usize) -> Self { <del> assert!(at <= self.len(), "`at` out of bounds"); </del> <ins> #[cold] #[inline(never)] fn assert_failed(at: usize, len: usize) -> ! { panic!("`at` split index (is {}) should be <= len (is {})", at, len); } if !(at <= self.len()) { assert_failed(at, self.len()); } </ins> let other_len = self.len - at; let mut other = Vec::with_capacity(other_len);

Discussion:
I've spotted, that panic message could've provided details on what values led to this panic, instead of mentioning condition only. Generally speaking this and some other s in Vec could've been more detailed. If it's okay to step in, I'd like to offer my help. In case of I'd suggest calling this instead I find this more informative than Candidates for improval: aforementioned : : : :
Does triaging mean a green light for this suggestion?
No, I just apply the relevant labels. :)
Though this is a small change with little time required to fix, so I'd just make the PR if I were you. :)
Note: uses the same kind of assertion in (as the old check had aliasing issues). Depending on which PR lands first, we should make sure it gets the same panic message as the others.
I think it makes sense to follow the message, that is being currently printed, when trying to access element out of bounds via . Current message template is . I followed this idiom to keep it consistent.
Change:
{ let old_count = self.err_count(); let result = f(); <del> let errors = self.err_count() - old_count; if errors == 0 { Ok(result) } else { Err(ErrorReported) } </del> <ins> if self.err_count() == old_count { Ok(result) } else { Err(ErrorReported) } </ins> } pub fn span_warn<S: Into<MultiSpan>>(&self, sp: S, msg: &str) { self.diagnostic().span_warn(sp, msg)

Discussion:
Build with overflow checking enabled: Then try compiling the following program (found by ):
The ICE is a regression, introduced in . The overflowing subtraction happens here: cc
( can also hit this when , see https://rust-)
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
This regression will unfortunately be included in 1.52.0 stable. Updating the labels.
This was discussed a bit on Zulip . I did a small amount of investigation, and found that the code that checks if "errors were generated" does not handle stashed errors correctly. It keeps a count of errors, but with stashed errors that count can go up and down at various times. In this particular case, an error is stashed and then stolen. The comment on the relevant function ("Remove this method, it should never be needed.") isn't really clear why it shouldn't be needed. In general, that error tracking logic needs to change to handle stashed errors correctly.
is a remnant from when we desired to check at the end of each stage and stop rustc from continuing. This is the easiest and safest course of action, but leads to the "waves of errors" experience. We've been moving away from that, but just removing blindly would cause a bunch of ICEs when codepaths that still assume things are well formed are exercised.
Change:
// dependency on this specific gcc. asm_args: vec!["-mcpu=msp430".to_string()], linker: Some("msp430-elf-gcc".to_string()), <ins> linker_is_gnu: false, </ins> // There are no atomic CAS instructions available in the MSP430 // instruction set, and the LLVM backend doesn't currently support

Discussion:
searched nightlies: from nightly-2021-04-19 to nightly-2021-06-01 regressed nightly: nightly-2021-05-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailssure , and optionally are installed. . Use commit specifically. . The bisector will use to look for whether compiling msp430 code succeeds or fails. On recent nightlies, msp430 linking using Rust will fail with something like this: When was merged, the default value for option from to . msp430 appears to have by , so is now set for msp430. If is set, Rust unconditionally to the linker options, which msp430 doesn't support. But technically, the msp430 backend does use the GNU linker. This is a bit of a bikeshed, but: I could set back to with a comment, or perhaps the logic to add the option? Does mean only "uses the GNU linker", or does it mean "uses the GNU linker plus specific options"? Thus, I'm opening an issue for possible feedback before fixing.
Thanks for the great writeup and context. cc: since author of the PR: any insights to share on this? Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Ooof, the linker errors strike again. In the short term, you could make the msp430 target explicitly set . In the longer term, we really need a better way of encoding all these linker capabilities :/ You're right, is pretty under-speced currently. Ideally I think I would instead replace it with a number of more specific flags for each specific feature we need.
Change:
if let Err(new_err) = ocx.eq_exp( &obligation.cause, obligation.param_env, <del> is_normalized_ty_expected, normalized_ty, expected_ty, </del> <ins> is_normalized_term_expected, normalized_term, data.term, </ins> ) { <del> (Some((data, is_normalized_ty_expected, normalized_ty, expected_ty)), new_err) </del> <ins> (Some((data, is_normalized_term_expected, normalized_term, data.term)), new_err) </ins> } else { (None, error.err) }

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
} } <ins> /// This is the symbol name of the given instance as seen by the linker. /// /// On 32-bit Windows symbols are decorated according to their calling conventions. pub fn linking_symbol_name_for_instance_in_crate<'tcx>( tcx: TyCtxt<'tcx>, symbol: ExportedSymbol<'tcx>, instantiating_crate: CrateNum, ) -> String { use rustc_target::abi::call::Conv; let mut undecorated = symbol_name_for_instance_in_crate(tcx, symbol, instantiating_crate); let target = &tcx.sess.target; if !target.is_like_windows { // Mach-O has a global "_" suffix and `object` crate will handle it. // ELF does not have any symbol decorations. return undecorated; } let x86 = match &target.arch[..] { "x86" => true, "x86_64" => false, // Only x86/64 use symbol decorations. _ => return undecorated, }; let instance = match symbol { ExportedSymbol::NonGeneric(def_id) | ExportedSymbol::Generic(def_id, _) if tcx.is_static(def_id) => { None } ExportedSymbol::NonGeneric(def_id) => Some(Instance::mono(tcx, def_id)), ExportedSymbol::Generic(def_id, substs) => Some(Instance::new(def_id, substs)), // DropGlue always use the Rust calling convention and thus follow the target's default // symbol decoration scheme. ExportedSymbol::DropGlue(..) => None, // NoDefId always follow the target's default symbol decoration scheme. ExportedSymbol::NoDefId(..) => None, }; let (conv, args) = instance .map(|i| { tcx.fn_abi_of_instance(ty::ParamEnv::reveal_all().and((i, ty::List::empty()))) .unwrap_or_else(|_| bug!("fn_abi_of_instance({i:?}) failed")) }) .map(|fnabi| (fnabi.conv, &fnabi.args[..])) .unwrap_or((Conv::Rust, &[])); // Decorate symbols with prefices, suffices and total number of bytes of arguments. // Reference: https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 let (prefix, suffix) = match conv { Conv::X86Fastcall => ("@", "@"), Conv::X86Stdcall => ("_", "@"), Conv::X86VectorCall => ("", "@@"), _ => { if x86 { undecorated.insert(0, '_'); } return undecorated; } }; let args_in_bytes: u64 = args .iter() .map(|abi| abi.layout.size.bytes().next_multiple_of(target.pointer_width as u64 / 8)) .sum(); format!("{prefix}{undecorated}{suffix}{args_in_bytes}") } </ins> fn wasm_import_module_map(tcx: TyCtxt<'_>, cnum: CrateNum) -> FxHashMap<DefId, String> { // Build up a map from DefId to a `NativeLib` structure, where // `NativeLib` internally contains information about

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!