jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected at least one digit in exponent --> $DIR/invalid-const-in-body.rs:2:5 | LL |     2.0E |     ^^^^ error: aborting due to previous error </ins>

Discussion:
Found with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression in nightly-2022-09-18 from ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-04 to nightly-2022-11-07 regressed nightly: nightly-2022-09-18 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: x86_64-apple-darwin </details
For the record, this isn't dependent on return type, which is a separate error. This also ICEs:
This don't ICE: I guess it's because terminated because the error type error.
Yeah, still needs to implement the trait in the -- this ICEs, for example:
I can take a look at this, unless you're already working on this
I think compiler-errors already submitted a PR to fix this, PR linked above, but he did not claim this issue.
Oh thanks, didn't see this.
Change:
}) // Assert that there is always such a frame. .unwrap(); <ins> // Assert that the frame we look at is actually executing code currently // (`current_source_info` is None when we are unwinding and the frame does // not require cleanup). </ins> let loc = frame.loc.unwrap(); <ins> // If this is a `Call` terminator, use the `fn_span` instead. </ins> let block = &frame.body.basic_blocks()[loc.block]; <del> assert_eq!(block.statements.len(), loc.statement_index); debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; </del> <ins> if loc.statement_index == block.statements.len() { debug!( "find_closest_untracked_caller_location:: got terminator {:?} ({:?})", block.terminator(), block.terminator().kind ); if let TerminatorKind::Call { fn_span, .. } = block.terminator().kind { return fn_span; } </ins> } <del> unreachable!(); </del> <ins> // This is a different terminator (such as `Drop`) or not a terminator at all // (such as `box`). Use the normal span. frame.body.source_info(loc).span </ins> } /// Allocate a `const core::panic::Location` with the provided filename and line/column numbers.

Discussion:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.
Change:
/// [`Pin<P>`]: ../pin/struct.Pin.html /// [`pin module`]: ../../std/pin/index.html #[stable(feature = "pin", since = "1.33.0")] <ins> #[rustc_on_unimplemented( on(_Self = "std::future::Future", note = "consider using `Box::pin`",), message = "`{Self}` cannot be unpinned" )] </ins> #[lang = "unpin"] pub auto trait Unpin {}

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
impl_stable_hash_via_hash!(SymbolManglingVersion); <del> #[derive(Clone, Copy, PartialEq, Hash)] </del> <ins> #[derive(Clone, Copy, Debug, PartialEq, Hash)] </ins> pub enum DebugInfo { None, Limited,

Discussion:
On macOS rustc runs dsymutil to generate debug info files. This invocation incorrectly ignores dsymutil's output and exit status. rustc thus succeeds even if dsymutil fails or crashes. Example: in , dsymutil crashed and left behind a corrupt .dSYM file. rustc nevertheless succeeded, thereby confusing the user after the debugger ignored that bad debug info. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc ignoring :
claim
Change:
Command::new(&build.initial_rustc).arg("--version").arg("--verbose")); let local_release = local_version_verbose .lines().filter(|x| x.starts_with("release:")) <del> .next().unwrap().trim_left_matches("release:").trim(); </del> <ins> .next().unwrap().trim_start_matches("release:").trim(); </ins> let my_version = channel::CFG_RELEASE_NUM; if local_release.split('.').take(2).eq(my_version.split('.').take(2)) { build.verbose(&format!("auto-detected local-rebuild {}", local_release));

Discussion:
After +
src/bootstrap changes from should probably be backported to beta
I think this can be closed now
Change:
/// /// Note that the best effort is made to ensure that the time waited is /// measured with a monotonic clock, and not affected by the changes made to <del> /// the system time. </del> <ins> /// the system time.  This function is susceptible to spurious wakeups. /// Condition variables normally have a boolean predicate associated with /// them, and the predicate must always be checked each time this function /// returns to protect against spurious wakeups.  Additionally, it is /// typically desirable for the time-out to not exceed some duration in /// spite of spurious wakes, thus the sleep-duration is decremented by the /// amount slept.  Alternatively, use the `wait_timeout_until` method /// to wait until a condition is met with a total time-out regardless /// of spurious wakes. </ins> /// /// The returned [`WaitTimeoutResult`] value indicates if the timeout is /// known to have elapsed.

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
}; if self.config.print_step_timings && !self.config.dry_run { <del> println!("[TIMING] {:?} -- {}.{:03}", step, dur.as_secs(), dur.subsec_millis()); </del> <ins> let step_string = format!("{:?}", step); let brace_index = step_string.find("{").unwrap_or(0); let type_string = type_name::<S>(); println!( "[TIMING] {} {} -- {}.{:03}", &type_string.strip_prefix("bootstrap::").unwrap_or(type_string), &step_string[brace_index..], dur.as_secs(), dur.subsec_millis() ); </ins> } {

Discussion:
While debugging the CI failure in , I saw the following output in the logs: The first one is and the second I think is , by the fields it has. But we should just print that in the debug logs rather than having to guess. label +A-contributor-roadblock +C-enhancement
This will be annoying to fix because we'll have to remove for and implement it by hand. Maybe we could introduce a new macro making it easier? The module name is available through
label +E-medium +E-mentor +A-rustbuild
The way to go is likely to add type_name to the timing print rather than solely relying on Debug.
Change:
llvm_components: Option<Vec<&'a str>>, } <del> pub fn check(path: &Path, bad: &mut bool) { crate::walk::walk(path, |path, _is_dir| filter_not_rust(path), &mut |entry, content| { </del> <ins> pub fn check(tests_path: &Path, bad: &mut bool) { crate::walk::walk(tests_path, |path, _is_dir| filter_not_rust(path), &mut |entry, content| { </ins> let file = entry.path().display(); let mut header_map = BTreeMap::new(); iter_header(content, &mut |HeaderLine { revision, directive, .. }| {

Discussion:
Tests doing codegen for specific targets need directives. These are the tests that are currently missing the directives and failing if LLVM is built without various aarch64/arm/thumb components or wasm. [ ] testsrun-makeprint-target-list [ ] testsrun-makeprint-to-output [ ] testsrun-makeprint-cfg [ ] testsrun-maketarget-without-atomic-cas Originally posted by in
E.g. for this looks a bit awkward, maybe we can dump , where is shamelessly stolen from tidy: Between this directive and , it is not exactly very clear what's happening.

In noticed was failing for (and other experimental llvm components) on the CI builder with (specifically ) it was already noticed that seemed to fail for . Is this expected? Or what is the expected test behavior when is ran (on the CI builder)? Or is it expected that we should skip trying to run this check for the and other experimental llvm component targets? Update: this is also true for experimental llvm components , , and , not too sure what the correct behavior is. Currently these targets are skipped by 's check.
Is there any COMPILETESTNEEDSALLLLVMCOMPONENTS set by us for this jobs?. It seems like the same issue. I will check it later.
Well, I'm not familiar with rmake. However, the right logic should be like: If is not set and do not have the , then we could skip it. is set at , and it is only used at now.
Ah thank you, that sounds about right.
Change:
<ins> // check-pass #![crate_type = "lib"] #![feature(transmutability)] use std::mem::BikeshedIntrinsicFrom; pub struct Context; pub fn is_maybe_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src, Context>, { } // The `T` here should not have any effect on checking // if transmutability is allowed or not. fn function_with_generic<T>() { is_maybe_transmutable::<(), ()>(); } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
searched toolchains nightly-2023-04-13 through nightly-2023-04-17 Regression in nightly-2023-04-15 searched toolchains through Regression in Attempting to search unrolled perf builds Found commits ["", "", "", "", "", "", "", "", ""] Regression in cc
claim
Thanks, I'll take a look at this
Change:
<ins> fn main() { let target: Target = create_target(); target.get(0); // correct arguments work target.get(10.0); // (used to crash here) //~^ ERROR mismatched types } // must be generic fn create_target<T>() -> T { unimplemented!() } // unimplemented trait, but contains function with the same name pub trait RandomTrait { fn get(&mut self); // but less arguments } struct Target; impl Target { // correct function with arguments pub fn get(&self, data: i32) { unimplemented!() } } </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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
<ins> // aux-build:proc_macro_sequence.rs // Regression test for issue #62831: Check that multiple sequences with the same span in the // left-hand side of a macro definition behave as if they had unique spans, and in particular that // they don't crash the compiler. #![feature(proc_macro_hygiene)] #![allow(unused_macros)] extern crate proc_macro_sequence; // When ignoring spans, this macro has the same macro definition as `generated_foo` in // `proc_macro_sequence.rs`. macro_rules! manual_foo { (1 $x:expr $($y:tt,)*   //~ERROR `$x:expr` may be followed by `$y:tt` $(= $z:tt)*  //~ERROR `$x:expr` may be followed by `=` ) => {}; } proc_macro_sequence::make_foo!(); //~ERROR `$x:expr` may be followed by `$y:tt` //~^ERROR `$x:expr` may be followed by `=` fn main() {} </ins>

Discussion:
Steps to reproduce: Extract the archive Run Run The following generated macro is a likely source of error: However, directly putting this macro does not seem to cause a compiler crash: It appears that the crash only occurs when the macro-by-example generated from a proc-macro. The full error message: Using gives a similar result: You can try removing the first one or two parts in the macro pattern and the error disappears.
cc
cc
The offending code is here: TBH, I'm not really sure what it is checking, and I don't have time to look into it right now (work is busy)... Sorry about that. It seems that the procmacro is somehow generating some tokens or TokenTrees (especially in a [i.e. a token repetition]) that don't have spans somehow. is that even possible? It looks like pnkfelix wrote this code originally 4 years ago. It hasn't been touched in years. do you know if there have been any changes in proc_macros that could have exposed this behavior?
Change:
providers.const_eval_validated = const_eval::const_eval_validated_provider; providers.const_eval_raw = const_eval::const_eval_raw_provider; providers.const_caller_location = const_eval::const_caller_location; <del> providers.const_field = |tcx, param_env_and_value| { let (param_env, (value, field)) = param_env_and_value.into_parts(); const_eval::const_field(tcx, param_env, None, field, value) }; </del> providers.destructure_const = |tcx, param_env_and_value| { let (param_env, value) = param_env_and_value.into_parts(); const_eval::destructure_const(tcx, param_env, value)

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
self.sess.gated_spans.gate(sym::async_closure, span); } <del> let capture_clause = self.parse_capture_clause(); </del> <ins> let capture_clause = self.parse_capture_clause()?; </ins> let decl = self.parse_fn_block_decl()?; let decl_hi = self.prev_token.span; let body = match decl.output {

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
use rustc_hir::{GenericParamKind, ImplItemKind, TraitItemKind}; use rustc_infer::infer::outlives::env::OutlivesEnvironment; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; <del> use rustc_infer::infer::{self, TyCtxtInferExt}; </del> <ins> use rustc_infer::infer::{self, InferCtxt, TyCtxtInferExt}; </ins> use rustc_infer::traits::util; use rustc_middle::ty::error::{ExpectedFound, TypeError}; use rustc_middle::ty::util::ExplicitSelf; <del> use rustc_middle::ty::InternalSubsts; </del> use rustc_middle::ty::{ <del> self, AssocItem, DefIdTree, Ty, TypeFoldable, TypeFolder, TypeSuperFoldable, TypeVisitable, </del> <ins> self, AssocItem, DefIdTree, TraitRef, Ty, TypeFoldable, TypeFolder, TypeSuperFoldable, TypeVisitable, </ins> }; <ins> use rustc_middle::ty::{FnSig, InternalSubsts}; </ins> use rustc_middle::ty::{GenericParamDefKind, ToPredicate, TyCtxt}; use rustc_span::Span; use rustc_trait_selection::traits::error_reporting::TypeErrCtxtExt;

Discussion:
Essentially, if my trait has and my impl has the compiler panics. Note that the code is invalid and compilation should fail. <!-- 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. --: Note that I'm using which is experimental. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This happens for all type mismatches in the arguments (but not the arity!) A : <details<summaryWith the following backtrace: </summary</details
When not using a normal , the proper error is emitted here inside : But something gets messed up with the return position impl trait in trait desugaring that doesn't make this work (the arity check above does work). claim
Change:
/// /// # Panics /// <del> /// This function will panic if `rhs` is 0 or if `self` is -1 and `rhs` is /// `Self::MIN`. This behavior is not affected by the `overflow-checks` flag. </del> <ins> /// This function will panic if `rhs` is 0 or if `self` is `Self::MIN` /// and `rhs` is -1. This behavior is not affected by the `overflow-checks` flag. </ins> /// /// # Examples ///

Discussion:
The documentation of and for any signed integer type, e.g.: In the "Panics" section it says "This function will panic if is 0 or if is -1 and is .", but I believe this is the wrong way around: the panic happens on , not on , as (correctly) explained in and all other related functions. Also, is there any situation where someone would want over ? Mathematically, should really just be 0, that it panics is more of an implementation artifact (the corresponding division overflows). Maybe it would be a good idea to add something like "If this is a problem, use instead." to the documentation of ? Though in most applications will probably be positive anyway. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
the error is also present on and .
Change:
<ins> error[E0716]: temporary value dropped while borrowed --> $DIR/escaping-bounds-2.rs:10:31 | LL |     let func = get_func::<T>(&String::new()); |                               ^^^^^^^^^^^^^ - temporary value is freed at the end of this statement |                               | |                               creates a temporary value which is freed while still in use LL |     drop(func); |          ---- borrow later used here | help: consider using a `let` binding to create a longer lived value | LL ~     let binding = String::new(); LL ~     let func = get_func::<T>(&binding); | error: aborting due to previous error For more information about this error, try `rustc --explain E0716`. </ins>

Discussion:
Check out ICU4X (tested on commit ), and build : However this started happening in our nightly CI since (one nightly before this one). The PR must have landed in the recent past. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Working on bisection, so far I have this
regressed commit: <detailsbash cargo bisect-rustc --start 2023-10-28 --end 2023-10-30 </details
Regression is , cc
Change:
path_str, disambiguator, extra_fragment: extra_fragment.map(String::from), <del> link_text, </del> <ins> link_text: link_text.to_owned(), </ins> })) }

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
// dependent alignment #[no_mangle] pub fn small_array_alignment(x: [i8; 4]) -> [i8; 4] { <del> // CHECK: [[VAR:%[0-9]+]] = load i32, i32* %{{.*}}, align 1 </del> <ins> // CHECK: [[VAR:%[0-9]+]] = load {{(i32, )?}}i32* %{{.*}}, align 1 </ins> // CHECK: ret i32 [[VAR]] x }

Discussion:
Hrm, yeah, the IR format changed from 3.6 to 3.7. In this case, it's just the extra result type in the instructions. Making that optional by changing to something like should help with that. If you still have a build using LLVM 3.6 around, it'd be great if you could create a patch for this. If not, let me know and I'll create one this evening.
I will give it a try. I am not planning to switch to 3.7 right now as there is no official release yet.
This is fixed.
Change:
desc: "use of a `~[T]` vector", default: allow, }), <ins> ("raw_pointer_deriving", LintSpec { lint: RawPointerDeriving, desc: "uses of #[deriving] with raw pointers are rarely correct", default: warn, }), </ins> ]; /*

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.