jiebi/CodeConvo huggingface dataset:
Change:
self.queries.on_disk_cache.as_ref() } <del> #[cfg(parallel_compiler)] pub unsafe fn deadlock(self, registry: &rustc_rayon_core::Registry) { rustc_query_system::query::deadlock(self, registry) } </del> pub(super) fn encode_query_results( self, encoder: &mut on_disk_cache::CacheEncoder<'_, 'tcx>,

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. --code from glacier <!-- 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 this is the alt master rustc, installed via <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This features a parallel-compiler-only bug. It is a variant of It is ultimately a blocker for and might be a blocker for but itself does not need to be fixed any time soon.
Remark from
This is not a problem with the implementation logic of the deadlock handler, but a very hard-to-trace thread scheduling vulnerability. If we add the following non-functional statement in of the function, this problem will disappear. Get rid of in deadlock handler can fix this. I just submited a to fix a set of ui test failures, including this issue.
Change:
seen_rust_tags = !seen_other_tags || seen_rust_tags; data.no_run = true; } <del> x if allow_error_code_check && x.starts_with("edition") => { // allow_error_code_check is true if we're on nightly, which // is needed for edition support </del> <ins> x if x.starts_with("edition") => { </ins> data.edition = x[7..].parse::<Edition>().ok(); } x if allow_error_code_check && x.starts_with("E") && x.len() == 5 => {

Discussion:
I have a fresh Rust library, started with , and I have the following in : edition2018 /// assert_eq!(1 + 1, 999) /// I can and this library. The doctest is obviously never run because is false. The output from confirms this, showing that zero test were run. lead me to believe the doctest should still work, even if marked as . is:
That's really strange! It works on nightly! I think it is due to this code: Was this maybe forgotten to be stabilized when editions were stabilized?
This still happens with Rust . I created a minimal project that demonstrates this bug at .
I posted PR to fix this.
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. #[deriving(Clone)] //~ ERROR `deriving` has been renamed to `derive` struct Foo; fn main() {} </ins>

Discussion:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.
Change:
<ins> // edition:2021 // check-pass union Union { value: u64, } fn main() { let u = Union { value: 42 }; let c = || { unsafe { u.value } }; c(); } </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: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
use rustc_hir::itemlikevisit::ItemLikeVisitor; use rustc_hir::{HirId, ItemLocalId}; <del> pub fn check_crate(hir_map: &Map<'_>) { </del> <ins> pub fn check_crate(hir_map: &Map<'_>, sess: &rustc_session::Session) { </ins> hir_map.dep_graph.assert_ignored(); let errors = Lock::new(Vec::new());

Discussion:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).
Change:
<ins> // check-pass // Regression test for issue #67844 // Ensures that we properly handle nested TAIT occurences // with generic parameters #![feature(type_alias_impl_trait)] trait WithAssoc { type AssocType; } trait WithParam<A> {} type Return<A> = impl WithAssoc<AssocType = impl WithParam<A>>; struct MyParam; impl<A> WithParam<A> for MyParam {} struct MyStruct; impl WithAssoc for MyStruct { type AssocType = MyParam; } fn my_fun<A>() -> Return<A> { MyStruct } fn my_other_fn<A>() -> impl WithAssoc<AssocType = impl WithParam<A>> { MyStruct } fn main() {} </ins>

Discussion:
Uncommenting the features and running in Nightly makes the complaints about unstable features go away while the panick stays. ~I’m not sure yet how to make a smaller example out of this.~ smaller examples in comments below This code was a step of me trying out if I could turn into a trait to get method syntax. () Errors:
Minimized:
Ah, neat, so it has nothing to do with closures or Fn traits.
T-compiler triage: I'm going to assume from 's self-assignment that this does not require discussion at T-compiler meeting. Removing I-nominated label.
Are nested type-alias-impl-traits even allowed by the RFC? If not, we should check and emit an error we we construct the type.
They are
any ideas how I can get my original example running though? I was starting with this function (which does compile) and wanted to give a name to its return type. The straightforward approach seems to be But the compiler is still unhappy with lifetimes currently, after your fix. I'm getting the following. At least it works without the lifetimes (i.e. after removing parametrization over 'a and replacing all occurrences of 'a with 'static).
Also I'm now (self-compiled master with the fix) getting a panic on this (admittedly incorrect) program: which didn't panic on the latest nightly (2020-02-13). Edit: I double checked: the behavior changes precisely over your 2 commits. Message is:
Can you open separate issues for each of those problems?
Okay, done ^^ (, )
Change:
pub use std::cell::RefMut as LockGuard; pub use std::cell::RefMut as MappedLockGuard; <del> pub use once_cell::unsync::OnceCell; </del> <ins> pub use std::lazy::OnceCell; </ins> use std::cell::RefCell as InnerRwLock; use std::cell::RefCell as InnerLock;

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
<ins> warning: unexpected `cfg` condition value --> $DIR/order-independant.rs:8:7 | LL | #[cfg(a)] |       ^- help: specify a config value: `= "b"` | = note: expected values for `a` are: `b` = note: `#[warn(unexpected_cfgs)]` on by default warning: unexpected `cfg` condition value --> $DIR/order-independant.rs:12:7 | LL | #[cfg(a = "unk")] |       ^^^^^^^^^ | = note: expected values for `a` are: `b` warning: 2 warnings emitted </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. --Run It works if the order of and is swapped. (e.i., ) <!-- 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. --: The backtrace points to in cc label +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry about that. Will fix it. claim
Change:
SubItem(hir::HirId), Expr(&'a hir::Expr), Pat(&'a hir::Pat), <ins> Arm(&'a hir::Arm), </ins> } pub enum Nested {

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
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. // xfail-pretty #[feature(managed_boxes, macro_rules)]; pub trait bomb { fn boom(@self, Ident); } pub struct S; impl bomb for S { fn boom(@self, _: Ident) { } } pub struct Ident { name: uint } // macro_rules! int3( () => ( unsafe { asm!( "int3" ); } ) ) macro_rules! int3( () => ( { } ) ) fn Ident_new() -> Ident { int3!(); Ident {name: 0x6789ABCD } } pub fn light_fuse(fld: @bomb) { int3!(); let f = || { int3!(); fld.boom(Ident_new()); // *** 1 }; f(); } pub fn main() { let b = @S as @bomb; light_fuse(b); } </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
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. // xfail-pretty #[feature(managed_boxes, macro_rules)]; pub trait bomb { fn boom(@self, Ident); } pub struct S; impl bomb for S { fn boom(@self, _: Ident) { } } pub struct Ident { name: uint } // macro_rules! int3( () => ( unsafe { asm!( "int3" ); } ) ) macro_rules! int3( () => ( { } ) ) fn Ident_new() -> Ident { int3!(); Ident {name: 0x6789ABCD } } pub fn light_fuse(fld: @bomb) { int3!(); let f = || { int3!(); fld.boom(Ident_new()); // *** 1 }; f(); } pub fn main() { let b = @S as @bomb; light_fuse(b); } </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
}); } else if matches!( meta_item.name_or_empty(), <del> sym::C | sym::simd | sym::transparent </del> <ins> sym::Rust | sym::C | sym::simd | sym::transparent </ins> ) || int_type_of_word(meta_item.name_or_empty()).is_some() { recognised = true;

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' File: --snippet: 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: --
Regression in nightly-2023-08-26
Change:
body: &Expr, fn_decl_span: Span, ) -> hir::ExprKind<'hir> { <del> // Lower outside new scope to preserve `is_in_loop_condition`. let fn_decl = self.lower_fn_decl(decl, None, false, None); self.with_new_scopes(move |this| { </del> <ins> let (body_id, generator_option) = self.with_new_scopes(move |this| { </ins> let prev = this.current_item; this.current_item = Some(fn_decl_span); let mut generator_kind = None;

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
Doesn't ICE on stable or beta label: regression-from-stable-to-nightly
searched nightlies: from nightly-2020-11-25 to nightly-2020-11-29 regressed nightly: nightly-2020-11-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: </detailsMaybe ?
Assigning and removing as in the prioritization working group.
- would you be up for fixing this bug or temporarily reverting PR presuming it is the cause?
Change:
nocapture: nocapture, color: color, quiet: quiet, <ins> test_threads: test_threads, </ins> }; Some(Ok(test_opts))

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
//! More documentation can be found in each respective module below, and you can //! also check out the `src/bootstrap/README.md` file for more information. <ins> #![deny(warnings)] </ins> extern crate build_helper; extern crate cmake; extern crate filetime;

Discussion:
When you compile rust you get: Regression of cc Maybe rustbuild should be compiled with to prevent errors like these in the future?
cc
Yeah when we fix this let's tag rustbuild with
Change:
let mut typeck_results = self.fcx.typeck_results.borrow_mut(); // All valid indexing looks like this; might encounter non-valid indexes at this point. <del> let base_ty = typeck_results.expr_ty_adjusted_opt(&base).map(|t| t.kind()); </del> <ins> let base_ty = typeck_results .expr_ty_adjusted_opt(&base) .map(|t| self.fcx.resolve_vars_if_possible(t).kind()); </ins> if base_ty.is_none() { // When encountering `return [0][0]` outside of a `fn` body we can encounter a base // that isn't in the type table. We assume more relevant errors have already been

Discussion:
Upstream ticket: I tried this code: I expected to see this happen: explanation The code compiles on but fails to build on rustc master which I assumes makes this a regression: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- version --<!-- 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<!-- 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 --
cargo-bisect-rustc says the regression is caused by
Maybe ?
cc
I assume this is the cause of the error:
MCVE:
Could be .
Reverting fixes the regression. The regression also appears in the for , but it appears either it was overlooked or the decision was made to merge anyway? cc
Assigning as and removing .
we probably have to update something here:
label E-needs-bisection E-needs-mcve
Change:
<ins> intra-links-warning-crlf.rs eol=crlf </ins>

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
{ let def_ids = dump_mir_def_ids(tcx, single); <del> let use_subgraphs = def_ids.len() > 1; </del> <ins> let mirs = def_ids .iter() .flat_map(|def_id| { if tcx.is_const_fn_raw(*def_id) { vec![tcx.optimized_mir(*def_id), tcx.mir_for_ctfe(*def_id)] } else { vec![tcx.instance_mir(ty::InstanceDef::Item(ty::WithOptConstParam::unknown( *def_id, )))] } }) .collect::<Vec<_>>(); let use_subgraphs = mirs.len() > 1; </ins> if use_subgraphs { writeln!(w, "digraph __crate__ {{")?; } <del> for def_id in def_ids { let body = &tcx.optimized_mir(def_id); write_mir_fn_graphviz(tcx, body, use_subgraphs, w)?; </del> <ins> for mir in mirs { write_mir_fn_graphviz(tcx, mir, use_subgraphs, w)?; </ins> } if use_subgraphs {

Discussion:
The working example in builds fine, but if I add it panics. Repro: It builds fine: Panics with : <details<summaryBacktrace</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the panic was by you. Could you say a few words on what the issue here? I'd be happy to investigate further and fix, but I have no idea where to start.
That's an oversight by me. In you instead need to do something similar to mir printing. That is, use instead of , but also create a second dump for by additionally using to show the graph of the ctfe version of the const fn
is somewhat related, as we should probably first fix that one and then deduplicate the mir selection logic between cfg printing and regular mir dumps.
has a smaller repro.
claim