jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: the `nomem` and `readonly` options are mutually exclusive --> $DIR/interpolated-idents.rs:13:13 | LL |               $options($pure, $nomem, $readonly, $preserves_flags, $noreturn, $nostack, $att_syntax)); |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | /     m!(in out lateout inout inlateout const sym LL | |        pure nomem readonly preserves_flags LL | |        noreturn nostack att_syntax options); | |____________________________________________- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: the `pure` and `noreturn` options are mutually exclusive --> $DIR/interpolated-idents.rs:13:13 | LL |               $options($pure, $nomem, $readonly, $preserves_flags, $noreturn, $nostack, $att_syntax)); |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | /     m!(in out lateout inout inlateout const sym LL | |        pure nomem readonly preserves_flags LL | |        noreturn nostack att_syntax options); | |____________________________________________- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: asm outputs are not allowed with the `noreturn` option --> $DIR/interpolated-idents.rs:10:32 | LL |               asm!("", $in(x) x, $out(x) x, $lateout(x) x, $inout(x) x, $inlateout(x) x, |                                  ^^^^^^^^^  ^^^^^^^^^^^^^  ^^^^^^^^^^^  ^^^^^^^^^^^^^^^ ... LL |       m!(in out lateout inout inlateout const sym |  _____- | |_____| | |_____| | |_____| | | LL | |        pure nomem readonly preserves_flags LL | |        noreturn nostack att_syntax options); | |                                            - | |____________________________________________| | |____________________________________________in this macro invocation | |____________________________________________in this macro invocation | |____________________________________________in this macro invocation |                                              in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors </ins>

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
); self.add_typo_suggestion(err, suggestion, ident.span); <ins> let import_suggestions = self.lookup_import_candidates( ident, Namespace::MacroNS, parent_scope, |res| match res { Res::Def(DefKind::Macro(MacroKind::Bang), _) => true, _ => false, }, ); show_candidates(err, None, &import_suggestions, false, true); </ins> if macro_kind == MacroKind::Derive && (ident.name == sym::Send || ident.name == sym::Sync) { let msg = format!("unsafe traits like `{}` should be implemented explicitly", ident); err.span_note(ident.span, &msg);

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 this code: I expected to see this happen: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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. --: Also not available in stable.
Change:
Some(tcx.typeck_root_def_id(def_id)) } Node::Item(item) => match item.kind { <del> ItemKind::OpaqueTy(hir::OpaqueTy { .. }) => { </del> <ins> ItemKind::OpaqueTy(hir::OpaqueTy { origin: hir::OpaqueTyOrigin::FnReturn(fn_def_id) | hir::OpaqueTyOrigin::AsyncFn(fn_def_id), in_trait, .. }) => { if in_trait { assert!(matches!(tcx.def_kind(fn_def_id), DefKind::AssocFn)) } else { assert!(matches!(tcx.def_kind(fn_def_id), DefKind::AssocFn | DefKind::Fn)) } Some(fn_def_id.to_def_id()) } ItemKind::OpaqueTy(hir::OpaqueTy { origin: hir::OpaqueTyOrigin::TyAlias, .. }) => { </ins> let parent_id = tcx.hir().get_parent_item(hir_id); assert_ne!(parent_id, hir::CRATE_OWNER_ID); debug!("generics_of: parent of opaque ty {:?} is {:?}", def_id, parent_id);

Discussion:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
// BasicBlock rustc_index::newtype_index! { <ins> /// A node in the MIR [control-flow graph][CFG]. /// /// There are no branches (e.g., `if`s, function calls, etc.) within a basic block, which makes /// it easier to do [data-flow analyses] and optimizations. Instead, branches are represented /// as an edge in a graph between basic blocks. /// /// Basic blocks consist of a series of [statements][Statement], ending with a /// [terminator][Terminator]. Basic blocks can have multiple predecessors and successors, /// however there is a MIR pass ([`CriticalCallEdges`]) that removes *critical edges*, which /// are edges that go from a multi-successor node to a multi-predecessor node. This pass is /// needed because some analyses require that there are no critical edges in the CFG. /// /// Read more about basic blocks in the [rustc-dev-guide][guide-mir]. /// /// [CFG]: https://rustc-dev-guide.rust-lang.org/appendix/background.html#cfg /// [data-flow analyses]: ///     https://rustc-dev-guide.rust-lang.org/appendix/background.html#what-is-a-dataflow-analysis /// [`CriticalCallEdges`]: ../../rustc_mir/transform/add_call_guards/enum.AddCallGuards.html#variant.CriticalCallEdges /// [guide-mir]: https://rustc-dev-guide.rust-lang.org/mir/ </ins> pub struct BasicBlock { derive [HashStable] DEBUG_FORMAT = "bb{}",

Discussion:
modify labels: A-mir T-doc C-enhancement E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I would be interested in doing this :) claim
Should this issue be on rustc-dev-guide?
I'm not sure if it's covered there, but I meant in terms of a doc comment on the struct.
Ok, take a look around https://rustc-dev- then. But you might want to discuss around Zulip what the convention is for doc-comments.
Hmm, I think most of the items in MIR have doc comments. I can ask on Zulip though.
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. // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro)] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn emit_unchanged(_args: TokenStream, input: TokenStream) -> TokenStream { input } </ins>

Discussion:
An ICE occurs when invoking a procedural macro attribute on the root of a crate with . Relevant backtrace frames: This happens on the latest nightly . cc
If you haven't started on this one I'll go ahead and take a crack at it since people are stumbling on it.
That second unwrap is which is infallible. That's kind of misleading, but okay.
Change:
fn inject_counters(&'a mut self) { //////////////////////////////////////////////////// // Compute coverage spans from the `CoverageGraph`. <del> let coverage_spans = CoverageSpans::generate_coverage_spans( </del> <ins> let Some(coverage_spans) = CoverageSpans::generate_coverage_spans( </ins> self.mir_body, self.fn_sig_span, self.body_span, &self.basic_coverage_blocks, <del> ); </del> <ins> ) else { // No relevant spans were found in MIR, so skip instrumenting this function. return; }; </ins> //////////////////////////////////////////////////// // Create an optimized mix of `Counter`s and `Expression`s for the `CoverageGraph`. Ensure

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
drop(linker); save_temp_bitcode(cgcx, &module, "lto.input"); <del> // Fat LTO also suffers from the invalid DWARF issue similar to Thin LTO. // Here we rewrite all `DICompileUnit` pointers if there is only one `DICompileUnit`. // This only works around the problem when codegen-units = 1. // Refer to the comments in the `optimize_thin_module` function for more details. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); unsafe { llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2) }; if !cu2.is_null() { let _timer = cgcx.prof.generic_activity_with_arg("LLVM_fat_lto_patch_debuginfo", &*module.name); unsafe { llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1) }; save_temp_bitcode(cgcx, &module, "fat-lto-after-patch"); } </del> // Internalize everything below threshold to help strip out more modules and such. unsafe { let ptr = symbols_below_threshold.as_ptr();

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61522-array-len-succ.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:4:40 | LL | pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                        ^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:8:24 | LL |     fn inner(&self) -> &[u8; COUNT + 1] { |                        ^^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors </ins>

Discussion:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61522-array-len-succ.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:4:40 | LL | pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                        ^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:8:24 | LL |     fn inner(&self) -> &[u8; COUNT + 1] { |                        ^^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors </ins>

Discussion:
This code ran in the latest nightly(2019-11-19) does not compile: And it prints this error message
Reduced:
that gives a different error, because isn't defined. Perhaps you meant something like:
This appears to be working now.
Change:
self.extra_lifetime_params_map.remove(&id).unwrap_or_default() } <ins> fn remap_extra_lifetime_params(&mut self, from: NodeId, to: NodeId) { let lifetimes = self.extra_lifetime_params_map.remove(&from).unwrap_or_default(); self.extra_lifetime_params_map.insert(to, lifetimes); } </ins> fn decl_macro_kind(&self, def_id: LocalDefId) -> MacroKind { self.builtin_macro_kinds.get(&def_id).copied().unwrap_or(MacroKind::Bang) }

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
Regression in nightly-2023-08-29 Regression in cc
Change:
)*) } <del> div_impl! { usize u8 u16 u32 u64 isize i8 i16 i32 i64 f32 f64 } </del> <ins> div_impl_integer! { usize u8 u16 u32 u64 isize i8 i16 i32 i64 } macro_rules! div_impl_float { ($($t:ty)*) => ($( #[stable(feature = "rust1", since = "1.0.0")] impl Div for $t { type Output = $t; #[inline] fn div(self, other: $t) -> $t { self / other } } forward_ref_binop! { impl Div, div for $t, $t } )*) } div_impl_float! { f32 f64 } </ins> /// The `Rem` trait is used to specify the functionality of `%`. ///

Discussion:
Using Google I can find lots of old arguments over how integer division should work in Rust, but I cannot find anything in the reference, the API docs for the integer types, or the API docs for the trait that says what was actually decided. (And the documentation seems to imply that , , and may not all do the same thing.) This is further confused by the integer type documentation apparently sometimes using to refer to integer division and sometimes to mathematical division. (I can't come up with out any other reasonable interpretation of in the documentation.) It would be nice if this were clearly documented somewhere, since this varies between languages and is one of the main confusions with integer arithmetic.
talks about 'overflow' and mentions wrapping, but you're right that we can surface this better.
This is about rounding, not wrapping. We use LLVM's , which rounds towards zero (and has the same sign as the dividend). We should document this (the documentation for currently lies_, claiming that it rounds towards negative infinite).
This should also leave a warning, because integer / integer is not always desired and happens by accident. Just a thought if anyone is reading this.
Change:
} }; cargo.env(profile_var("DEBUG"), debuginfo_level.to_string()); <ins> if let Some(opt_level) = &self.config.rust_optimize.get_opt_level() { cargo.env(profile_var("OPT_LEVEL"), opt_level); } </ins> if !self.config.dry_run() && self.cc.borrow()[&target].args().iter().any(|arg| arg == "-gz") { rustflags.arg("-Clink-arg=-gz");

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
<ins> error: `dyn B` implements `Deref` with supertrait `(dyn A + 'static)` as output --> $DIR/migrate-lint-deny.rs:20:12 | LL |     take_a(b) |            ^ | note: the lint level is defined here --> $DIR/migrate-lint-deny.rs:1:9 | LL | #![deny(deref_into_dyn_supertrait)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #89460 <https://github.com/rust-lang/rust/issues/89460> error: aborting due to previous error </ins>

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. --I tried this code: I expected to see this happen: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!--<details<summaryBacktrace</summary<p</p</details--(not applicable) <!-- 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 -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 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
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.
Change:
<ins> #![feature(non_lifetime_binders)] //~^ WARN is incomplete and may not be safe pub fn foo() where for<V> V: Sized, { } pub fn bar() where for<V> V: IntoIterator, { } fn main() { foo(); //~^ ERROR the size for values of type `V` cannot be known at compilation time bar(); //~^ ERROR the size for values of type `V` cannot be known at compilation time //~| ERROR `V` is not an iterator } </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
I can't reproduce this? On master, that is.
Ah oops, looks like I minimized wrongly, give me a sec...
This should do: `
Minimized -- PR coming up.