jiebi/CodeConvo huggingface dataset:
Change:
use crate::{ cell::{Cell, UnsafeCell}, fmt, <ins> marker::PhantomData, </ins> mem::{self, MaybeUninit}, ops::{Deref, Drop}, panic::{RefUnwindSafe, UnwindSafe},

Discussion:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :
Change:
<ins> // compile-fail // edition:2018 #![feature(async_await)] #![feature(existential_type)] #![feature(impl_trait_in_bindings)] //~^ WARNING the feature `impl_trait_in_bindings` is incomplete // See issue 60414 ///////////////////////////////////////////// // Reduction to `impl Trait` struct Foo<T>(T); trait FooLike { type Output; } impl<T> FooLike for Foo<T> { type Output = T; } mod impl_trait { use super::*; trait Trait { type Assoc; } /// `T::Assoc` can't be normalized any further here. fn foo_fail<T: Trait>() -> impl FooLike<Output=T::Assoc> { //~^ ERROR: type mismatch Foo(()) } } ///////////////////////////////////////////// // Same with lifetimes in the trait mod lifetimes { use super::*; trait Trait<'a> { type Assoc; } /// Missing bound constraining `Assoc`, `T::Assoc` can't be normalized further. fn foo2_fail<'a, T: Trait<'a>>() -> impl FooLike<Output=T::Assoc> { //~^ ERROR: type mismatch Foo(()) } } fn main() {} </ins>

Discussion:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.
Change:
let mut fulfillment_errors = Vec::new(); let mut applicable_candidates: Vec<_> = infcx.probe(|_| { <del> let universe = infcx.create_next_universe(); </del> // Regions are not considered during selection. <del> // FIXME(non_lifetime_binders): Here we are "truncating" or "flattening" the universes // of type and const binders. Is that correct in the selection phase? See also #109505. let self_ty = tcx.replace_escaping_bound_vars_uncached( self_ty, FnMutDelegate { regions: &mut |_| tcx.lifetimes.re_erased, types: &mut |bv| { tcx.mk_placeholder(ty::PlaceholderType { universe, bound: bv }) }, consts: &mut |bv, ty| { tcx.mk_const(ty::PlaceholderConst { universe, bound: bv }, ty) }, }, ); </del> <ins> let self_ty = self_ty .fold_with(&mut BoundVarEraser { tcx, universe: infcx.create_next_universe() }); struct BoundVarEraser<'tcx> { tcx: TyCtxt<'tcx>, universe: ty::UniverseIndex, } // FIXME(non_lifetime_binders): Don't assign the same universe to each placeholder. impl<'tcx> TypeFolder<TyCtxt<'tcx>> for BoundVarEraser<'tcx> { fn interner(&self) -> TyCtxt<'tcx> { self.tcx } fn fold_region(&mut self, r: ty::Region<'tcx>) -> ty::Region<'tcx> { if r.is_late_bound() { self.tcx.lifetimes.re_erased } else { r } } fn fold_ty(&mut self, ty: Ty<'tcx>) -> Ty<'tcx> { match *ty.kind() { ty::Bound(_, bv) => self.tcx.mk_placeholder(ty::PlaceholderType { universe: self.universe, bound: bv, }), _ => ty.super_fold_with(self), } } fn fold_const( &mut self, ct: ty::Const<'tcx>, ) -> <TyCtxt<'tcx> as rustc_type_ir::Interner>::Const { assert!(!ct.ty().has_escaping_bound_vars()); match ct.kind() { ty::ConstKind::Bound(_, bv) => self.tcx.mk_const( ty::PlaceholderConst { universe: self.universe, bound: bv }, ct.ty(), ), _ => ct.super_fold_with(self), } } } let InferOk { value: self_ty, obligations } = infcx.at(&cause, param_env).normalize(self_ty); </ins> candidates .iter()

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 --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim
Change:
}]) } <ins> struct Linker(llvm::LinkerRef); impl Linker { fn new(llmod: ModuleRef) -> Linker { unsafe { Linker(llvm::LLVMRustLinkerNew(llmod)) } } fn add(&mut self, bytecode: &[u8]) -> Result<(), ()> { unsafe { if llvm::LLVMRustLinkerAdd(self.0, bytecode.as_ptr() as *const libc::c_char, bytecode.len()) { Ok(()) } else { Err(()) } } } } impl Drop for Linker { fn drop(&mut self) { unsafe { llvm::LLVMRustLinkerFree(self.0); } } } </ins> /// Prepare "thin" LTO to get run on these modules. /// /// The general structure of ThinLTO is quite different from the structure of

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
<ins> error[E0282]: type annotations needed --> $DIR/issue-109905.rs:13:5 | LL |     <() as Trait<'static, _>>::m(()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `T` declared on the trait `Trait` error[E0282]: type annotations needed --> $DIR/issue-109905.rs:20:5 | LL |     Trait::<'static, _>::m(()); |     ^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `T` declared on the trait `Trait` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </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. --: This was also tried on with on Rust Playground, with the same error. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsWithout the fully qualified path, see commented code, the error is . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: Looking into this. claim label D-incorrect
Change:
// If this is a SwitchInt(const _), then we can just evaluate the constant and return. let discr = match discr { Operand::Constant(constant) => { <del> let bits = eval_mono_const(constant); </del> <ins> let bits = eval_mono_const(constant)?; </ins> return Some((bits, targets)); } Operand::Move(place) | Operand::Copy(place) => place,

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. --I encountered an ICE while playing with 's that has to do with its comptime assertions. I have not been able to reproduce the ICE when inlining the constant value in which the checks are performed. Perhaps it is related with the fact that originally there was a crate boundary? I have an inkling const blocks' merger might be to blame. <!-- 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
It would be useful to have a minimal example that doesn't involve the entire tagged_ptr crate.
Reduced: , needs This bisects to cc label A-monomorphization S-has-mcve -E-needs-mcve
ye olde "compiler must not crash on invalid code" problem
PR with a fix is up. Thanks for catching this before the bug hit beta
No, thanks to you all for not only fixing it, but running this amazing project every day. I hope I have more time in the future so that I can spend it here and be a part of this.
Change:
<ins> -include ../tools.mk # FIXME: ignore freebsd/windows # on windows `rustc --dep-info` produces Makefile dependency with # windows native paths (e.g. `c:pathtolibfoo.a`) # but msys make seems to fail to recognize such paths, so test fails. ifneq ($(shell uname),FreeBSD) ifndef IS_WINDOWS all: $(RUSTC) --emit dep-info main.rs grep "input.txt" $(TMPDIR)/main.d grep "input.bin" $(TMPDIR)/main.d else all: endif else all: endif </ins>

Discussion:
This causes cargo to misbehave: Tagging as E-easy, since the appropriate fix.
I'm going to try and fix this.
After reading the files and , I have come up with a plan. This is a little bit tricky, since with , we know that we are including utf-8 content, so it's safe to store the source as a String in a . We don't know that for , but I don't think we actually need to track the contents anyways, so I'm passing to . Currently building, I'll see if that fixes it.
This should have been Can someone with power close?
Indeed!
Change:
/// Basic usage: /// /// ``` <del> /// #![feature(iter_once_with)] /// </del> /// use std::iter; /// /// // one is the loneliest number

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
// Finally, resolve all regions. let outlives_env = OutlivesEnvironment::new(param_env); <del> infcx.resolve_regions_and_report_errors(impl_did, &outlives_env); </del> <ins> infcx.check_region_obligations_and_report_errors(impl_did, &outlives_env); </ins> CoerceUnsizedInfo { custom_kind: kind } })

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
if self.clean and os.path.exists(build_dir): shutil.rmtree(build_dir) env = os.environ.copy() <ins> # `CARGO_BUILD_TARGET` breaks bootstrap build. # See also: <https://github.com/rust-lang/rust/issues/70208>. if "CARGO_BUILD_TARGET" in env: del env["CARGO_BUILD_TARGET"] </ins> env["RUSTC_BOOTSTRAP"] = '1' env["CARGO_TARGET_DIR"] = build_dir env["RUSTC"] = self.rustc()

Discussion:
cc
I've hit this many times, and using fixes the issue for me.
Unfortunately, that doesn't help. I got the same error again after removing entire dir. I think I find the problem. does not encounter for env (which I set in my file).
Hence the bootstrap should be in rather than .
This line: We may need to remove in . Or support it properly.
I personally consider this a "user error" in some sense, in that there's a bunch of cargo flags you can set (either in .cargo/config or environment) that'll break x.py -- I don't think we should be removing them ourselves, personally, since it seems like it's hard to be sure that they're really not necessary. I would also not want to support them, though... However, with specifically, it seems fine to just drop it from the environment. I would accept a PR doing so in
Change:
//         Validate(Acquire, [_1: &ReFree(DefId(0/1:9 ~ validate_5[317d]::main[0]::{{closure}}[0]), BrEnv) [closure@NodeId(46)], _2: &ReFree(DefId(0/1:9 ~ validate_5[317d]::main[0]::{{closure}}[0]), BrAnon(0)) mut i32]); //         StorageLive(_3); //         StorageLive(_4); <ins> //         StorageLive(_5); </ins> //         Validate(Suspend(ReScope(Node(ItemLocalId(9)))), [(*_2): i32]); <del> //         _4 = &ReErased mut (*_2); //         Validate(Acquire, [(*_4): i32/ReScope(Node(ItemLocalId(9)))]); //         _3 = move _4 as *mut i32 (Misc); </del> <ins> //         _5 = &ReErased mut (*_2); //         Validate(Acquire, [(*_5): i32/ReScope(Node(ItemLocalId(9)))]); //         _4 = move _5 as *mut i32 (Misc); //         _3 = move _4; </ins> //         EndRegion(ReScope(Node(ItemLocalId(9)))); //         StorageDead(_4); <ins> //         StorageDead(_5); </ins> //         Validate(Release, [_0: bool, _3: *mut i32]); //         _0 = const write_42(move _3) -> bb1; //     }

Discussion:
In , reported several NLL errors in dependencies of the servo crate. later minimized one of those errors into : which yields: Removing feature(nll) makes the code work, so probably this is an NLL bug.
I'd like to take a look at this.
Explicitly casting to fixes the issue: My guess is that there's an issue with the automatic coercion from to . I'll investigate further.
It turns out you can remove one layer of indirection and still get the same error:
Change:
<ins> fn main() { a.5.2E+ //~^ ERROR: unexpected token: `5.2E+` //~| ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `5.2E+` //~| ERROR: expected at least one digit in exponent } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Affected versions: probably all versions since that panic was introduced, I tried nightly 2021-11-07 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsA quick inspection of the code shows that the similar case is handled the same as : So if I had to guess I would say that the match is missing this one case, so should be handled the same as : But no idea what does that code even do, it has a FIXME by so maybe he knows better. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
ShouldWarnAboutField::Yes(is_positional) } <del> fn warn_multiple_dead_codes( </del> <ins> // # Panics // All `dead_codes` must have the same lint level, otherwise we will intentionally ICE. // This is because we emit a multi-spanned lint using the lint level of the `dead_codes`'s // first local def id. // Prefer calling `Self.warn_dead_code` or `Self.warn_dead_code_grouped_by_lint_level` // since those methods group by lint level before calling this method. fn lint_at_single_level( </ins> &self, dead_codes: &[LocalDefId], participle: &str,

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
intrinsics::abort() } <del> rust_panic_with_hook(&mut PanicPayload::new(msg), None, Location::caller()); </del> <ins> let loc = Location::caller(); return crate::sys_common::backtrace::__rust_end_short_backtrace(move || { rust_panic_with_hook(&mut PanicPayload::new(msg), None, loc) }); </ins> struct PanicPayload<A> { inner: Option<A>,

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
"itertools", "minifier", "once_cell", <del> "rayon", </del> "regex", "rustdoc-json-types", "serde", "serde_json", "smallvec", "tempfile", <ins> "threadpool", </ins> "tracing", "tracing-subscriber", "tracing-tree",

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
/// /// handler.join().unwrap(); /// ``` <ins> /// /// [naming-threads]: ./index.html#naming-threads </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn name(&self) -> Option<&str> { self.cname().map(|s| unsafe { str::from_utf8_unchecked(s.to_bytes()) } )

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR: