jiebi/CodeConvo huggingface dataset:
Change:
return None; } Expect(expect_id) | ForceWarning(Some(expect_id)) => { <del> // Diagnostics created before the definition of `HirId`s are // unstable and can not yet be stored. Instead, they are // buffered until the `LintExpectationId` is replaced by a // stable one by the `LintLevelsBuilder`. </del> if let LintExpectationId::Unstable { .. } = expect_id { <del> // We don't call TRACK_DIAGNOSTIC because we wait for the // unstable ID to be updated, whereupon the diagnostic will // be passed into this method again. self.unstable_expect_diagnostics.push(diagnostic); return None; </del> <ins> unreachable!(); // this case was handled at the top of this function </ins> } self.fulfilled_expectations.insert(expect_id.normalize()); if let Expect(_) = diagnostic.level {

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: matches!(, Error Allow)'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [earlylintchecks] perform lints prior to macro expansion [hircrate] getting the crate HIR -- label +F-stmtexpr_attributes
bisects to :thinking: cc edit: ah the assertion was there...
Change:
use rustc_middle::ty::visit::{TypeVisitable, TypeVisitableExt}; use rustc_middle::ty::{self, GenericArgs, Ty, TyCtxt, TypeSuperVisitable, TypeVisitor}; use rustc_span::def_id::LocalDefId; <del> use rustc_span::Span; </del> <ins> use rustc_span::{Span, DUMMY_SP}; </ins> use rustc_target::spec::abi::Abi; use rustc_trait_selection::error_reporting::traits::ArgKind; use rustc_trait_selection::traits;

Discussion:
I'm writing this as a continuation of While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It most recently worked on: Not 100% sure, some explanations have been made in original issue
This is because the signature of  is: We only extract an async closure bound from cases where there is bound on the trait, which is not. There isn't even a supertrait bound that constrains the output type. I also do not expect this to ever be fixed, because that would require overly complicating the closure signature inference algorithm in ways that make me quite uncomfortable[^1][^2]. The correct solution is to rework the futures crate to have first-class async closure support, so for now I'd recommend just ascribing your type names. Sorry! [^1]: Firstly, this would break if another blanket implementation for were ever . [^2]: Secondly, the combinator shouldn't really be using bounds either -- it should be using bounds.
Alternatively, would fix this when paired with a slight adjustment to the closure signature inference that I'd be happy to make, but it seems like that PR is blocked.
Change:
<ins> error[E0499]: cannot borrow `*x` as mutable more than once at a time --> $DIR/issue-110929-generator-conflict-error-ice.rs:9:9 | LL |         let _c = || yield *&mut *x; |                  --             -- first borrow occurs due to use of `*x` in generator |                  | |                  first mutable borrow occurs here LL |         || _ = &mut *x; |         ^^          -- second borrow occurs due to use of `*x` in closure |         | |         second mutable borrow occurs here LL | LL |     }; |     - first borrow might be used here, when `_c` is dropped and runs the destructor for generator error: aborting due to previous error For more information about this error, try `rustc --explain E0499`. </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
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-21 searched toolchains through Regression in :thinking: cc
Well, it is not unreachable it turns out huh
I believe this is a MRE:
Change:
features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "lp64d".into(), max_atomic_width: Some(64), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_musl::opts() }, }

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
/// Compares two given types, eliding parts that are the same between them and highlighting /// relevant differences, and return two representation of those types for highlighted printing. fn cmp(&self, t1: Ty<'tcx>, t2: Ty<'tcx>) -> (DiagnosticStyledString, DiagnosticStyledString) { <ins> debug!("cmp(t1={}, t1.kind={:?}, t2={}, t2.kind={:?})", t1, t1.kind, t2, t2.kind); // helper functions </ins> fn equals<'tcx>(a: Ty<'tcx>, b: Ty<'tcx>) -> bool { match (&a.kind, &b.kind) { (a, b) if *a == *b => true,

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
trace!("visit_statement: statement={:?} location={:?}", statement, location); match statement.kind { <del> StatementKind::Assign(..) => { </del> <ins> StatementKind::Assign(..) | StatementKind::SetDiscriminant { .. } => { </ins> self.super_statement(statement, location); } StatementKind::FakeRead(FakeReadCause::ForMatchedPlace, _) => {

Discussion:
Leaving this issue as a reminder for It should be as simple as adding a checkplace call to the <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This bug appears in as well: Might as well stop letting inline ASM through to MIRI while you're at it.
I'm taking this one :P
assign
Change:
<ins> error: this operation will panic at runtime --> $DIR/index-bounds.rs:4:14 | LL |     let _n = [64][200]; |              ^^^^^^^^^ index out of bounds: the length is 1 but the index is 200 | = note: `#[deny(unconditional_panic)]` on by default error: this operation will panic at runtime --> $DIR/index-bounds.rs:8:14 | LL |     let _n = [64][u32::MAX as usize - 1]; |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ index out of bounds: the length is 1 but the index is 4294967294 error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
debug!("{}.super_relate_consts(a = {:?}, b = {:?})", relation.tag(), a, b); let tcx = relation.tcx(); <del> let eagerly_eval = |x: &'tcx ty::Const<'tcx>| { // FIXME(eddyb) this doesn't account for lifetime inference variables // being erased by `eval`, *nor* for the polymorphic aspect of `eval`. // That is, we could always use `eval` and it will just return the // old value back if it doesn't succeed. if !x.val.needs_infer() { return x.eval(tcx, relation.param_env()).val; } x.val }; </del> <ins> let eagerly_eval = |x: &'tcx ty::Const<'tcx>| x.eval(tcx, relation.param_env()).val; </ins> // FIXME(eddyb) doesn't look like everything below checks that `a.ty == b.ty`. // We could probably always assert it early, as `const` generic parameters

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
further minimized: Looks like the generator code incorrectly handles somewhere :thinking:
PR is up. I noticed that an old stable rustc doesn't ICE, so marking as such and nominating the PR for beta backport.
Change:
where F: FnOnce(&mut Self, T), { <del> let mut computation = FlagComputation::new(); for bv in value.bound_vars() { match bv { ty::BoundVariableKind::Ty(_) => { computation.flags |= TypeFlags::HAS_TY_LATE_BOUND; } ty::BoundVariableKind::Region(_) => { computation.flags |= TypeFlags::HAS_RE_LATE_BOUND; } ty::BoundVariableKind::Const => { computation.flags |= TypeFlags::HAS_CT_LATE_BOUND; } } } </del> <ins> let mut computation = FlagComputation::bound_var_flags(value.bound_vars()); </ins> f(&mut computation, value.skip_binder());

Discussion:
: The bug seems to be present in the latest nightly at well as stable. <details<summary<strongBacktrace</strong</summary<p</p</details
It seems like this has something to do with appearing multiple times, once in 's bound, then again in 's. Switching the order of the two bounds seems to avoid the error.
Regression in nightly-2021-07-25 commit[0] 2021-07-23: Auto merge of - JohnTitor:rollup-dht22jk, r=JohnTitor commit[1] 2021-07-23: Auto merge of - JohnTitor:get-by-key-enum-part-2, r=oli-obk commit[2] 2021-07-24: Auto merge of - SparrowLii:MaybeTrait, r=wesleywiser commit[3] 2021-07-24: Auto merge of - Mark-Simulacrum:bump-version, r=Mark-Simulacrum commit[4] 2021-07-24: Auto merge of - In-line:zircon-thread-name, r=JohnTitor commit[5] 2021-07-24: Auto merge of - crlf0710:rich_vtable, r=nikomatsakis commit[6] 2021-07-24: Auto merge of - Aaron1011:inert-warn, r=petrochenkov commit[7] 2021-07-24: Auto merge of - Manishearth:rollup-b09njin, r=Manishearth commit[8] 2021-07-24: Auto merge of - BoxyUwU:cgd-subst-ice, r=nikomatsakis
Change:
/////////////////////////////////////////////////////////////////////////// // ADJUSTMENTS <del> fn adjust_self_ty(&mut self, unadjusted_self_ty: Ty<'tcx>, pick: &probe::Pick<'tcx>) -> Ty<'tcx> { </del> <ins> fn adjust_self_ty( &mut self, unadjusted_self_ty: Ty<'tcx>, pick: &probe::Pick<'tcx>, ) -> Ty<'tcx> { </ins> // Commit the autoderefs by calling `autoderef` again, but this // time writing the results into the various tables. let mut autoderef = self.autoderef(self.span, unadjusted_self_ty); <del> let (_, n) = autoderef.nth(pick.autoderefs).unwrap(); </del> <ins> let (_, n) = match autoderef.nth(pick.autoderefs) { Some(n) => n, None => { self.tcx.sess.delay_span_bug( syntax_pos::DUMMY_SP, &format!("failed autoderef {}", pick.autoderefs), ); return self.tcx.types.err; } }; </ins> assert_eq!(n, pick.autoderefs); let mut adjustments = autoderef.adjust_steps(self, Needs::None);

Discussion:
The compiler correctly errors about the ambiguous types, but also panics on this code:
Also reproduces on nightly. Panic happens here:
triage: P-medium. removing nomination label. reasoning: has a PR. tagging as P-medium (since it does produce useful error message before ICE'ing), and removing nomination label.
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn foo(a: &'let int) { } //~ ERROR invalid lifetime name fn bar(a: &'static int) { } fn baz<'self>(a: &'self int) { } fn main() { } </ins>

Discussion:
e.g. is currently valid, but shouldn't be. (Note that is, and should remain, a valid lifetime.)
Note that this will only be possible after a snapshot, since the snapshot compiler currently requires lifetimes called . (Tagged easy although asking for some guidance in IRC may be useful since the parser isn't exactly easy to navigate.)
Why do we need to disallow this?
Consistency, maybe? ( suggested it.)
motivation was both consistency and to allow for possible future special uses. In particular I think could possibly be put to better use in the future.
Change:
if paths.is_empty() || builder.config.include_default_paths { for (desc, should_run) in v.iter().zip(&should_runs) { <del> if desc.default && should_run.is_really_default { </del> <ins> if desc.default && should_run.is_really_default() { </ins> for pathset in &should_run.paths { desc.maybe_run(builder, pathset); }

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
<ins> // run-rustfix fn main() { demo = 1; //~ ERROR cannot find value `demo` in this scope dbg!(demo); //~ ERROR cannot find value `demo` in this scope x = "x"; //~ ERROR cannot find value `x` in this scope println!("x: {}", x); //~ ERROR cannot find value `x` in this scope if x == "x" { //~^ ERROR cannot find value `x` in this scope println!("x is 1"); } y = 1 + 2; //~ ERROR cannot find value `y` in this scope println!("y: {}", y); //~ ERROR cannot find value `y` in this scope } </ins>

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
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. #![crate_type="lib"] pub mod foo { pub use super::*; } </ins>

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
#![feature(alloc_jemalloc, alloc_system)] <del> #[cfg(not(target_env = "msvc"))] </del> <ins> #[cfg(not(any(target_env = "msvc", target_os = "bitrig")))] </ins> extern crate alloc_jemalloc; <del> #[cfg(target_env = "msvc")] </del> <ins> #[cfg(any(target_env = "msvc", target_os = "bitrig"))] </ins> extern crate alloc_system; fn main() {

Discussion:
After the new snapshots landed, test failures showed up.
failures: [run-pass] run-pass/allocator- [run-pass] run-pass/allocator-
it looks like the outstanding jemalloc issues are finally biting us.
Change:
<ins> // run-pass // From https://github.com/rust-lang/rust/issues/65727 const _: &i32 = { let x = &(5, false).0; x }; fn main() { let _: &'static i32 = &(5, false).0; } </ins>

Discussion:
Consider the following code: The borrow of the tuple field in is promoted out along with the tuple itself in accordance with the rules for rvalue static promotion. However, in the , the mechanism for promotion does not remove / for the tuple, causing to dangle. On stable, this is only caught during const-evaluation and results in a warning. If this warning is supressed, an ICE occurs. On nightly, the MIR borrow checker prevents this from happening, and this code is rejected instead. It should be accepted in all contexts.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue_39823.rs extern crate issue_39823; use issue_39823::{RemoteC, RemoteG}; #[derive(Debug, PartialEq)] struct LocalC(u32); #[derive(Debug, PartialEq)] struct LocalG<T>(T); fn main() { let virtual_localc : &Fn(_) -> LocalC = &LocalC; assert_eq!(virtual_localc(1), LocalC(1)); let virtual_localg : &Fn(_) -> LocalG<u32> = &LocalG; assert_eq!(virtual_localg(1), LocalG(1)); let virtual_remotec : &Fn(_) -> RemoteC = &RemoteC; assert_eq!(virtual_remotec(1), RemoteC(1)); let virtual_remoteg : &Fn(_) -> RemoteG<u32> = &RemoteG; assert_eq!(virtual_remoteg(1), RemoteG(1)); } </ins>

Discussion:
Not on 1.15. cc
Fun note: another bug fixed on my shimmir branch. Not that I really want to merge it to 1.16/1.17.
Minified: I think we should just have the first commit of shimmir to fix this.
triage: P-high
Change:
use rustc_middle::ty::{self, DefIdTree, TyCtxt}; use rustc_session::lint; use rustc_span::symbol::{sym, Symbol}; <ins> use std::mem; </ins> // Any local node that may call something in its body block should be // explored. For example, if it's a live Node::Item that is a

Discussion:
This should compile without warnings (): Yet it warns: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this only occurs in const patterns. This produces no warnings (): Output:
Cc – this only occurs with inline const expressions; no warning is triggered with const items.
claim
Change:
<ins> // edition:2018 async fn fun() { [1; ().await]; //~^ error: `await` is only allowed inside `async` functions and blocks //~| error: `.await` is not allowed in a `const` //~| error: `loop` is not allowed in a `const` //~| error: `.await` is not allowed in a `const` //~| error: the trait bound `(): std::future::Future` is not satisfied } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-22 searched commits: from to regressed commit:
Simplified: and cc ()
Fix up at