jiebi/CodeConvo huggingface dataset:
Change:
https://crater- https://crater- https://crater-
Might be related to
I've tried the first 2 crates (bonedaddy.ellidri and edu-sync), they compile on the current stable fail to compile on beta and nightly. Provisionally assigning P-high waiting for more investigation (). label -I-prioritize +P-high +T-compiler
bisected to commit , where in this commit originates the issue: Regression in i.e. rollup PR (Implement proposed API for ) (Simplify computation of killed borrows) (More nits) (add note for non-exhaustive matches with guards) (Fix invalid HTML DIV tag used in HEAD) (add myself to review for t-types stuff) label -e-needs-bisection
Bisection probably leads to cc TIL to look at the results, they help getting more context. They told me tha PR is actually commit
I'll take a look at this after RustConf.
Is it possible the bisection contained an error? I'm not seeing any possible connection. The errors seem unrelated, is not used anywhere in my PR, and is not even present in any of the three linked logs.
Ok, I give up on reproducing using the crate (in the latest nightlies the error changed, I can't track the original error anymore). So I've started again using the crate I now have a stable reproducible. I am now a bit more confident the regression is in (specifically ) cc (I see in that patch some code that is in the stacktraces). sorry for the ping and thanks for pointing me into the right direction :)
No worries! Someone mentioned that it may have been incorrect at RustConf, but I wanted to have a chance to look into it myself before saying anything. I'll be unsubscribing from this issue; please ping if something needs my attention :)
small, but not yet minimal repro. Should be good enough for the test suite. I'm looking into a fix now.
I reverted all changes from and it does not appear to change behaviour. trying a local bisect on the minimal repro. edit: hmm weird, it also points to that PR. Trying again edit2: ok now it works, weird

Discussion:
// Opaque types can't have field projections, but we can instead convert // the current place in-place (heh) to the hidden type, and then apply all // follow up projections on that. <del> if node_ty != place_ty && place_ty.has_opaque_types() { </del> <ins> if node_ty != place_ty && matches!(place_ty.kind(), ty::Alias(ty::Opaque, ..)) { </ins> projections.push(Projection { kind: ProjectionKind::OpaqueCast, ty: node_ty }); } projections.push(Projection { kind, ty });

<ins> // edition: 2021 use std::future::Future; async fn bop() { fold(run(), |mut foo| async move { &mut foo.bar; }) } fn fold<Fut, F, U>(_: Foo<U>, f: F) where F: FnMut(Foo<U>) -> Fut, { loop {} } struct Foo<F> { bar: Vec<F>, } fn run() -> Foo<impl Future<Output = ()>> { //~^ ERROR type annotations needed loop {} } fn main() {} </ins>

<ins> error[E0282]: type annotations needed --> $DIR/opaque-cast-field-access-in-future.rs:22:17 | LL | fn run() -> Foo<impl Future<Output = ()>> { |                 ^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>
Change:
The 1.72.1 release was announced: Actually, this tag exists: However, this version does not seem to exist in GitHub Releases: It seems that this operation is usually done by a , so is there some problem with the automated release procedure?
I suspect we need to copy the release notes to master.
I tried to respond with , is this what you meant?
Why is the release not marked as ? What is the authoritative source of the version?
Good catch! At the moment, 1.71.1 is flagged as presumably since the release notes for 1.71.1 () were merged several hours after the ones for 1.72.1 (). I'm not a T-release member and I'm not super familiar with GitHub releases. is there a simple way to mark 1.72.1 as ?
Should be fixed.

Discussion:
<ins> Version 1.72.1 (2023-09-19) =========================== - [Adjust codegen change to improve LLVM codegen](https://github.com/rust-lang/rust/pull/115236) - [rustdoc: Fix self ty params in objects with lifetimes](https://github.com/rust-lang/rust/pull/115276) - [Fix regression in compile times](https://github.com/rust-lang/rust/pull/114948) - Resolve some ICE regressions in the compiler: - [#115215](https://github.com/rust-lang/rust/pull/115215) - [#115559](https://github.com/rust-lang/rust/pull/115559) </ins> Version 1.72.0 (2023-08-24) ==========================
Change:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.

Discussion:
"exclusive range pattern syntax is experimental" ); gate_all_legacy_dont_use!(try_blocks, "`try` blocks are unstable"); <ins> gate_all_legacy_dont_use!(auto_traits, "`auto` traits are unstable"); </ins> visit::walk_crate(&mut visitor, krate); }

fn parse_item_trait(&mut self, attrs: &mut AttrVec, lo: Span) -> PResult<'a, ItemInfo> { let unsafety = self.parse_unsafety(Case::Sensitive); // Parse optional `auto` prefix. <del> let is_auto = if self.eat_keyword(kw::Auto) { IsAuto::Yes } else { IsAuto::No }; </del> <ins> let is_auto = if self.eat_keyword(kw::Auto) { self.sess.gated_spans.gate(sym::auto_traits, self.prev_token.span); IsAuto::Yes } else { IsAuto::No }; </ins> self.expect_keyword(kw::Trait)?; let ident = self.parse_ident()?;

<ins> // check-pass #[cfg(FALSE)] auto trait Foo {} //~^ WARN `auto` traits are unstable //~| WARN unstable syntax can change at any point in the future, causing a hard error! fn main() {} </ins>

<ins> warning: `auto` traits are unstable --> $DIR/pre-cfg.rs:4:1 | LL | auto trait Foo {} | ^^^^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = warning: unstable syntax can change at any point in the future, causing a hard error! = note: for more information, see issue #65860 <https://github.com/rust-lang/rust/issues/65860> warning: 1 warning emitted </ins>

// compile-flags: --test #![feature(async_closure)] <ins> #![feature(auto_traits)] </ins> #![feature(box_patterns)] #![feature(const_trait_impl)] #![feature(decl_macro)]
Change:
Specifically the last assert in the Examples section: asserteq!( format!("l as binary is: {l:b}"), "l as binary is: " ); This example shows how to format the binary representation of an i32 and was probably meant to display all 32 bits, but actually only displays 30 bits because the alternate flag adds the prefix to the representation, which is included in the total width of the padding (which is mentioned in passing here: ). I think it would be useful to mention in that example that the prefix is included in the total width, and I would also suggest changing the example to use as that is probably what the reader is expecting when displaying a padded i32, <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hmm, you'd think Bors would have closed this automatically...
In the PR description you need to write something like " so that github will know they're associated. See .

Discussion:
/// assert_eq!(format!("l as binary is: {l:b}"), "l as binary is: 1101011"); /// /// assert_eq!( <del> ///     format!("l as binary is: {l:#032b}"), ///     "l as binary is: 0b000000000000000000000001101011" </del> <ins> ///     // Note that the `0b` prefix added by `#` is included in the total width, so we ///     // need to add two to correctly display all 32 bits. ///     format!("l as binary is: {l:#034b}"), ///     "l as binary is: 0b00000000000000000000000001101011" </ins> /// ); /// ``` #[stable(feature = "rust1", since = "1.0.0")]
Change:
I tried this code: Nightly fails running on MIPS emulator assertion failed left: right: Stable succeeds Looks like the top and bottom dwords are mixed up target is mips-unknown-linux-musl emulator is qemu-mips-static
This is probably related to
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This can be provoked on mips64 as well:
Is this what's causing these build failures when upgrading from 1.72.0 to 1.73.0? Just checking before I open a new bug. I get a bunch of these on slightly different floating-point values on mips64.
Floats are hell, and also this landed with 1.73: A new issue is a good idea.
Yeah I've also been getting lots of different floating point related issues on 1.73 on MIPS. I too would've thought they are related to the shifts, but the new apfloat code could also be the reason.
I applied the patch from and confirmed that it fixes the 1.73.0 bootstrap problem for me. I also tried the snippet from 's comment above and it did not assert after applying that patch.
It happened with , too. We stripped down the PoC to a few lines of LLVM IR code, and we reported to the . Turned out that it is exactly the same problem here.

Discussion:
<del> Subproject commit fef3d7b14ede45d051dc688aae0bb8c8b02a0566 </del> <ins> Subproject commit 7738295178045041669876bf32b0543ec8319a5c </ins>
Change:
<!-- 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
cc
reduced further:
reduced further:

Discussion:
visitor.assignments[local] = Set1::One(LocationExtended::Arg); } <del> if body.basic_blocks.len() > 2 { for (bb, data) in traversal::reverse_postorder(body) { visitor.visit_basic_block_data(bb, data); } } else { for (bb, data) in body.basic_blocks.iter_enumerated() { visitor.visit_basic_block_data(bb, data); } </del> <ins> // For SSA assignments, a RPO visit will see the assignment before it sees any use. // We only visit reachable nodes: computing `dominates` on an unreachable node ICEs. for (bb, data) in traversal::reverse_postorder(body) { visitor.visit_basic_block_data(bb, data); </ins> } for var_debug_info in &body.var_debug_info {

<ins> // Regression test for issue #116212. #![feature(never_type)] use std::mem::MaybeUninit; struct Foo { x: u8, y: !, } fn main() { let foo = unsafe { MaybeUninit::<Foo>::uninit().assume_init() }; } </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: note the duplicate <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
feature, not a bug: we want people to be very strongly discouraged, so we say it twice.
the more repetions, the more discouraged. lang_items should go up to 10.
Maybe we should print it in an infinite loop, just to be on the save side?
This is happening on as well.
claim The source of the problem is the decorator for which is adding two to the Diagnostic instead of one. I'm trying to dig further and decipher the marco-generated decorator code here: I also noticed that the behaviour seems to differ across gates. E.g. building this: emits one note for and two notes for : Not sure what's different about these gates. I'm new to this area, so if you can provide any pointers based on the above, please do.
This program tests all the internal gates: It produces the following output: Of the 21 internal gates, only the last 6 result in duplicate notes.
These should be more, there's a file somewhere that defines all the features but I can't check it right now on mobile
I think that should be all of them. This is super weird indeed, no idea
Thanks & I found what's different about gates with duplicate notes: they all have an associated issue. Here's the full list grepped from : Notice that the second last field in the last 6 lines is unlike the rest where it is . Apparently having an associated issue causes this problem.
The root cause is the being passed on this line: Its value is for gates that have an associated issue and for others. Since already has a attribute: this results in duplicates. The solution is to always pass for internal gates.

Discussion:
.chain(features.declared_lib_features.iter().map(|(name, span)| (name, span))) .filter(|(&name, _)| features.incomplete(name) || features.internal(name)) .for_each(|(&name, &span)| { <del> let note = rustc_feature::find_feature_issue(name, GateIssue::Language) .map(|n| BuiltinFeatureIssueNote { n }); </del> if features.incomplete(name) { <ins> let note = rustc_feature::find_feature_issue(name, GateIssue::Language) .map(|n| BuiltinFeatureIssueNote { n }); </ins> let help = HAS_MIN_FEATURES.contains(&name).then_some(BuiltinIncompleteFeaturesHelp); cx.emit_spanned_lint( INCOMPLETE_FEATURES, span, BuiltinIncompleteFeatures { name, note, help }, ); } else { <del> cx.emit_spanned_lint( INTERNAL_FEATURES, span, BuiltinInternalFeatures { name, note }, ); </del> <ins> cx.emit_spanned_lint(INTERNAL_FEATURES, span, BuiltinInternalFeatures { name }); </ins> } }); }

#[note] pub struct BuiltinInternalFeatures { pub name: Symbol, <del> #[subdiagnostic] pub note: Option<BuiltinFeatureIssueNote>, </del> } #[derive(Subdiagnostic)]
Change:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .

Discussion:
("trace_macros", Active), ("simd", Active), ("default_type_params", Active), <del> ("quote_tokens", Active), ("quote_expr", Active), ("quote_ty", Active), ("quote_item", Active), ("quote_pat", Active), ("quote_stmt", Active), </del> <ins> ("quote", Active), </ins> // These are used to test this portion of the compiler, they don't actually // mean anything

} else { for &quote in quotes.iter() { if id == self.sess.ident_of(quote) { <del> self.gate_feature(quote, path.span, quote + msg); </del> <ins> self.gate_feature("quote", path.span, quote + msg); </ins> } } }

#[feature(macro_rules, globs, struct_variant, managed_boxes)]; #[allow(unknown_features)]; // Note: remove it after a snapshot. <del> #[feature(quote_item, quote_expr)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod flate;

html_root_url = "http://static.rust-lang.org/doc/master")]; #[feature(macro_rules, globs, managed_boxes)]; <del> #[allow(unknown_features)]; #[feature(quote_expr)]; </del> <ins> #[allow(unknown_features)];// Note: remove it after a snapshot. #[feature(quote)]; </ins> #[deny(non_camel_case_types)];

// force-host <del> #[feature(globs, macro_registrar, macro_rules, quote_expr)]; </del> <ins> #[feature(globs, macro_registrar, macro_rules, quote)]; </ins> extern mod syntax;

// except according to those terms. // xfail-test Can't use syntax crate here <del> #[feature(quote_expr)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

// except according to those terms. // xfail-test Can't use syntax crate here <del> #[feature(quote_stmt)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

// xfail-pretty // xfail-test <del> #[feature(quote_expr, quote_ty, quote_item, quote_stmt, quote_pat)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

// except according to those terms. // xfail-test <del> #[feature(quote_expr, quote_tokens, quote_item, quote_pat, quote_stmt)]; </del> <ins> #[feature(quote)]; </ins> #[feature(managed_boxes)]; extern mod syntax;

// xfail-fast // xfail-android <del> #[feature(quote_expr)]; </del> <ins> #[feature(quote)]; </ins> #[deny(unused_variable)]; extern mod syntax;
Change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-06-03 Regression in Regression in ?
This is fixed by .
assign

Discussion:
// mir. match tcx.at(expr.span).lit_to_const(lit_input) { Ok(c) => return Some(c), <ins> Err(_) if lit_input.ty.has_aliases() => { // allow the `ty` to be an alias type, though we cannot handle it here return None; } </ins> Err(e) => { tcx.dcx().span_delayed_bug( expr.span,

<del> //@ known-bug: #116308 #![feature(adt_const_params)] pub trait Identity { type Identity; } impl<T> Identity for T { type Identity = Self; } pub fn foo<const X: <i32 as Identity>::Identity>() {} fn main() { foo::<12>(); } </del>

<ins> //@ check-pass #![feature(adt_const_params)] // Regression test for #116308 pub trait Identity { type Identity; } impl<T> Identity for T { type Identity = Self; } pub fn foo<const X: <i32 as Identity>::Identity>() {} fn main() { foo::<12>(); } </ins>
Change:
At various points, rustc may use to get a backtrace of the current thread such as if or similar functions are called. On Windows, this results in attempting to load the hardcoded path of rustc's PDB which, on normal user machines, never exists. Normally, this is fine and we just simply don't have debug symbols, but in some environments like build systems such as , filesystem accesses are monitored to enable fine-grained caching. If we try to load rustc's PDB in this environment, it will trigger build system errors: Since these paths won't generally resolve (unless you build rustc from source with debuginfo yourself), it would be nice to provide a way to turn this behavior off.
Modifying this to focus specifically on the behavior of as trying to load PDBs during an ICE isn't actually problematic for the stated use case.

Discussion:
<del> Subproject commit 99faef833f890fe89f1a959d89b951954118828b </del> <ins> Subproject commit e9da96eb452aa65e79e2342be700544afe509440 </ins>
Change:
File: mvce: original: Version information Command: Program output:
cc
I spent some time digging this, but I have no clue how is this happening yet.
Uh... isn't this regression from one of the dataflow const prop PRs? I don't think the is_global change caused
cc
When I reverted changes to problem disappeared. Edit: My hunch is this problem existed before but somehow covered it.

Discussion:
return body; } <ins> // If `mir_drops_elaborated_and_const_checked` found that the current body has unsatisfiable // predicates, it will shrink the MIR to a single `unreachable` terminator. // More generally, if MIR is a lone `unreachable`, there is nothing to optimize. if let TerminatorKind::Unreachable = body.basic_blocks[START_BLOCK].terminator().kind && body.basic_blocks[START_BLOCK].statements.is_empty() { return body; } </ins> run_optimization_passes(tcx, &mut body); body

// check-pass <del> // compile-flags: --emit=mir,link </del> <ins> // compile-flags: --emit=mir,link -Zmir-opt-level=4 </ins> // Checks that we don't ICE due to attempting to run const prop // on a function with unsatisifable 'where' clauses
Change:
The tests have regressed on Fedora since upgrading to Rust 1.73.0, and I can also reproduce this on toolchains. I expected to see this happen: all tests pass Instead, this happened: it passes in debug mode, but fails multiple tests in . For example: It most recently worked on: 1.72.1 : It's no better on or . As noted above, it also fails on Fedora rawhide's Rust 1.73.0 with LLVM 17. However, it passes on Fedora 38 with Rust 1.73.0 and LLVM 16, so it definitely seems like a codegen regression in 17. modify labels: +A-LLVM +T-compiler +regression-from-stable-to-stable -regression-untriaged
Doesn't happen when calling with a zero argument instead, so probably something gets miscompiled when atms() is inlined into at() and specialized for 0.
opt-bisect points towards a backend issue: IR for the function looks like this:
The issue is already introduced during the SDAG layer by a custom combine: This is interchanging to , which is obviously incorrect and should be instead.
That case is new in 17, , so it would seem to be a true regression, not just something that we were lucky to miss before due to other perturbations.
Indeed, all tests pass with: This also passes all , including that original . I haven't tried to add or update a specific test for this problem yet.
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Discussion:
<del> Subproject commit d404cba4e39df595710869988ded7cbe1104b52f </del> <ins> Subproject commit febc39711a7c91560eb0f0980916ae23c343b99d </ins>