jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for issue #61033. macro_rules! test2 { ( $(* $id1:ident)* $(+ $id2:ident)* ) => { $( //~ERROR meta-variable `id1` repeats 2 times $id1 + $id2 // $id1 and $id2 may repeat different numbers of times )* } } fn main() { test2! { * a * b + a + b + c } } </ins>

Discussion:
Given this test file: stable Rust errors like this: while on 1.36.0-nightly ( 2019-05-21) running on x86_64-unknown-linux-gnu:
caused by cc
Yay, we have a test case.
Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert and add the test case. Thanks ! But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. Checking that the Kleene operator used in the body is the same as that in the matcher Checking that all meta-variables used in the body are defined and in scope Checking that all meta-variables used in the body are repeating at the right depth Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway) So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macros... Thoughts?
Opened
there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start). I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).
Ok, makes sense. I will open another issue with these items so we can track them.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-87490.rs:9:5 | LL | fn follow(_: &str) -> <&str as StreamOnce>::Position { |                       ------------------------------ expected `usize` because of return type LL |     String::new |     ^^^^^^^^^^^ expected `usize`, found fn item | = note: expected type `usize` found fn item `fn() -> String {String::new}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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
can be replaced by any function item, e.g. or . Lifetime of must be bounded to a parameter, therefore does not work Regression in not sure which PR exactly though but I think modify labels: regression-from-stable-to-nightly
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
can actually also be replaced with or seemingly any type other than the return type in the function signature, but strangely leaving the function body empty does not trigger the ICE.
No longer ICEs since
Change:
<ins> error[E0597]: `n` does not live long enough --> $DIR/issue-69114-static-mut-ty.rs:19:15 | LL |         BAR = &n; |         ------^^ |         |     | |         |     borrowed value does not live long enough |         assignment requires that `n` is borrowed for `'static` ... LL | } | - `n` dropped here while still borrowed error[E0597]: `n` does not live long enough --> $DIR/issue-69114-static-mut-ty.rs:27:22 | LL |         BAR_ELIDED = &n; |         -------------^^ |         |            | |         |            borrowed value does not live long enough |         assignment requires that `n` is borrowed for `'static` ... LL | } | - `n` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
<!-- 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 : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
cmd.args(&args).env(dylib_path_var(), env::join_paths(&dylib_path).unwrap()); // Get the name of the crate we're compiling, if any. <del> let crate_name = args.windows(2).find(|args| args[0] == "--crate-name").and_then(|args| args[1].to_str()); </del> <ins> let crate_name = arg("--crate-name"); </ins> if let Some(crate_name) = crate_name { if let Some(target) = env::var_os("RUSTC_TIME") {

Discussion:
On , with a provided component: errors with: I'll try and see if I can reproduce it with to test suggestion:
Couldn't reproduce it with an , tried with also Does it have to be cross compiled from a different host?
Not sure what is necessary to reproduce it. In any case if you open a PR with the likely fix, I can run a try build on CI which you can then locally install to see if it fixes the issue.
Change:
PatKind::Variant { adt_def, variant_index, ref subpatterns, .. } => { let ref variant = adt_def.variants[variant_index]; <ins> let is_non_exhaustive = variant.is_field_list_non_exhaustive() && !cx.is_local(pat.ty); </ins> Some(Variant(variant.def_id)) .filter(|variant_constructor| variant_constructor == constructor) <del> .map(|_| patterns_for_variant(subpatterns, wild_patterns)) </del> <ins> .map(|_| patterns_for_variant(cx, subpatterns, wild_patterns, is_non_exhaustive)) </ins> } PatKind::Leaf { ref subpatterns } => { <del> Some(patterns_for_variant(subpatterns, wild_patterns)) </del> <ins> Some(patterns_for_variant(cx, subpatterns, wild_patterns, false)) </ins> } PatKind::Deref { ref subpattern } => {

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
pub use internal_impl::globbed::*; } <ins> extern "C" { /// dox pub fn extern_fn_documented(f: f32) -> f32; pub fn extern_fn_undocumented(f: f32) -> f32; //~^ ERROR: missing documentation for a function /// dox pub static EXTERN_STATIC_DOCUMENTED: u8; pub static EXTERN_STATIC_UNDOCUMENTED: u8; //~^ ERROR: missing documentation for a static /// dox pub type ExternTyDocumented; pub type ExternTyUndocumented; //~^ ERROR: missing documentation for a foreign type } </ins> fn main() {}

Discussion:
It seems like this lint should fire if you have an declaration without docs on it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-lint T-compiler C-bug
I think I know what causes this and will write a more general fix here this week. claim
the fix wasn't more general but it's a fix none the less
Change:
for debugging_option_str in &options.debugging_options_strs { compiler.arg("-Z").arg(&debugging_option_str); } <del> if no_run { </del> <ins> if no_run && !compile_fail { </ins> compiler.arg("--emit=metadata"); } compiler.arg("--target").arg(target.to_string());

Discussion:
The below code (in ) has three doc tests: first succeeds as expected. second test fails as expected: the constant would be and there is an attempt to subtract with overflow. third test should succeed as it has the exact same code as the second test but is marked as . However the test fails with the message “Test compiled successfully, but it's marked .” rust /// let works = cf::S::<u32::default(); /// (); /// rust /// let shouldfail = cf::S::<u64::default(); /// (); /// compilefail /// let shouldfail = cf::S::<u64::default(); /// (); ///
This is a consequence of how works. (and ) does the equivalent of (or the same as ), which does not perform all steps of compilation (like codegen and linking). One of the issues tracking this problem is . I'm not sure why rustdoc does not perform the full compilation steps for and .
Change:
<ins> error: multiple declared defaults --> $DIR/issue-105101.rs:3:10 | LL | #[derive(Default)] |          ^^^^^^^ ... LL |     A, |     - first default LL |     #[default] LL |     A, |     - additional default | = note: only one variant can be default = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0428]: the name `A` is defined multiple times --> $DIR/issue-105101.rs:8:5 | LL |     A, |     - previous definition of the type `A` here LL |     #[default] LL |     A, |     ^ `A` redefined here | = note: `A` must be defined only once in the type namespace of this enum error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0428`. </ins>

Discussion:
Found with a thread 'rustc' panicked at 'assertion failed: !suggestion.isempty()', <details<summaryBacktrace</summary</detailsFirst ICEd in nightly-2021-07-29, likely from ( which support for enums. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
PR is up at
Change:
use dataflow::BitDenotation; /// This calculates if any part of a MIR local could have previously been borrowed. <del> /// This means that once a local has been borrowed, its bit will always be set /// from that point and onwards, even if the borrow ends. You could also think of this /// as computing the lifetimes of infinite borrows. </del> <ins> /// This means that once a local has been borrowed, its bit will be set /// from that point and onwards, until we see a StorageDead statement for the local, /// at which points there is no memory associated with the local, so it cannot be borrowed. </ins> /// This is used to compute which locals are live during a yield expression for /// immovable generators. #[derive(Copy, Clone)]

Discussion:
cc
cc
I'm hitting this a lot at the moment-- any idea what the cause might be? I'd love to help get this resolved.
I'm sometimes able to fix it by moving conditions that out of the body of an expression.
It also seems to have regressed between and -- updating the compiler caused this to happen in more places.
Possibly related to ? cc
Trying to fix in more places and it looks like it's always related to temporaries-- if I make it and then use in the place I was using it usually solves the issue.
Smaller example: ()
cc this is blocking roll out of async/await in Fuchsia
Looked at this and pointed out that it looks like typechecking thinks that isn't live at the point (which is correct) but that MIR thinks it is live (which is incorrect). I tried searching through the diff to see if there were any related PRs, but so far the only thing I've found that touches MIR is , which seems like it shouldn't be related.
Is working on bisecting this.
I think the problem is that is borrowed by and because of this the generator transformation only uses and statements to calculate liveness. However we generate a statement for before its initialiser which contains the statement. So appears live during the statement, even though its storage isn't used for anything.
Bisection pointed to as the PR that made this worse (more code ICEs now), although the minimal test case still fails before and after. cc
minimal repro: This ICE only surfaces after
using instead of makes the ICE "go away"
Ah you need at the very least to use and initializations, not . AFAIK the type of a variable could be dead at a (lifetimes not ready yet). Arguably you could also have the time before moving out and a reinitialization also count as dead, e.g. doesn't really need to keep alive.
Change:
<ins> // Copyright 2015 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. // compile-flags: -C no-prepopulate-passes // CHECK: @VAR1 = constant i32 1, section ".test_one" #[no_mangle] #[link_section = ".test_one"] pub static VAR1: u32 = 1; pub enum E { A(u32), B(f32) } // CHECK: @VAR2 = constant {{.*}} { i32 0, i32 666, {{.*}} }, section ".test_two" #[no_mangle] #[link_section = ".test_two"] pub static VAR2: E = E::A(666); // CHECK: @VAR3 = constant {{.*}} { i32 1, float 1.000000e+00, {{.*}} }, section ".test_three" #[no_mangle] #[link_section = ".test_three"] pub static VAR3: E = E::B(1.); // CHECK: define void @fn1() {{.*}} section ".test_four" { #[no_mangle] #[link_section = ".test_four"] pub fn fn1() {} </ins>

Discussion:
I compile the code below: using compiler version 1.3.0-nightly ( 2015-07-27) with the following command line: As result I get the following symbol inside a produced rlib:
How'd you verify this? I tried a few variants myself and it looks like it works.
It's broken in Nightly release. Try the following code in after choosing 'Asm' and 'Nightly'.
Aha, looks like I was using an older nightly. cc some informal bisecting turns up as a suspicious commit
Yes, that bisection is correct; PR coming up.
Change:
// Vectors, even for non-power-of-two sizes, have the same layout as // arrays but don't count as aggregate types <ins> // While LLVM theoretically supports non-power-of-two sizes, and they // often work fine, sometimes x86-isel deals with them horribly // (see #115212) so for now only use power-of-two ones. </ins> if let FieldsShape::Array { count, .. } = self.layout.fields() <ins> && count.is_power_of_two() </ins> && let element = self.field(cx, 0) && element.ty.is_integral() {

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. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?

Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.
Change:
) -> Result<(), SelectionError<'tcx>> { debug!("assemble_candidates_from_impls(obligation={:?})", obligation); <ins> // Essentially any user-written impl will match with an error type, // so creating `ImplCandidates` isn't useful. However, we might // end up finding a candidate elsewhere (e.g. a `BuiltinCandidate` for `Sized) // This helps us avoid overflow: see issue #72839 // Since compilation is already guaranteed to fail, this is just // to try to show the 'nicest' possible errors to the user. if obligation.references_error() { return Ok(()); } </ins> self.tcx().for_each_relevant_impl( obligation.predicate.def_id(), obligation.predicate.skip_binder().trait_ref.self_ty(),

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
i: i32, } <ins> #[repr(packed, align(0x100))] pub struct S(u16); //~ ERROR type has conflicting packed and align representation hints #[repr(packed, align(0x100))] pub union U { //~ ERROR type has conflicting packed and align representation hints u: u16 } static B: U = U { u: 0 }; static A: S = S(0); </ins> fn main() {}

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 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: </details
Change:
<ins> // check-pass #![feature(adt_const_params, generic_const_exprs)] //~^ WARN the feature `adt_const_params` is incomplete and may not be safe to use and/or cause compiler crashes [incomplete_features] //~^^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes [incomplete_features] pub struct Changes<const CHANGES: &'static [&'static str]> where [(); CHANGES.len()]:, { changes: [usize; CHANGES.len()], } impl<const CHANGES: &'static [&'static str]> Changes<CHANGES> where [(); CHANGES.len()]:, { pub const fn new() -> Self { Self { changes: [0; CHANGES.len()], } } } pub fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
A reduced version: Tested in using
The other ICE block is also standalone
for the first example: ` Regression in :thinking: EDIT: same for the second snippet.
This is caused by Seems as if this issue takes care of FIXME ^^. Not sure what the right solution is, we originally tried to skip reborrows because implicit autorefs/autoderefs lead to confusing error messages given that we don't support derefs and refs in abstract consts. Maybe the right solution is to just clarify that autorefs/autoderefs happen there. Thoughts
No longer ICEs since (perhaps due to ?)
Change:
self.cat_pattern(place_with_id, subpat, op)?; } <ins> PatKind::Ref(subpat, _) if self.cx.typeck_results().skipped_ref_pats().contains(pat.hir_id) => { self.cat_pattern(place_with_id, subpat, op)?; } </ins> PatKind::Box(subpat) | PatKind::Ref(subpat, _) => { // box p1, &p1, &mut p1. we can ignore the mutability of // PatKind::Ref since that information is already contained

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim