jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --With as a dependency. <!-- 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 is repeated for what seems like every parallel compilation unit.
It appeared to be related to running out of space in the target directory.
Thank you for opening the issue and that explanation. This is probably fixed by (which will be in 1.76 but not 1.75) but I'll try to reproduce the crash just in case it isn't fixed by that.
The reproducer script I cooked up for reproduces this ICE backtrace on stable, so I'm linking this to that PR.

Discussion:
debug!("save: remove old file"); } Err(err) if err.kind() == io::ErrorKind::NotFound => (), <del> Err(err) => { sess.dcx().emit_err(errors::DeleteOld { name, path: path_buf, err }); return; } </del> <ins> Err(err) => sess.dcx().emit_fatal(errors::DeleteOld { name, path: path_buf, err }), </ins> } let mut encoder = match FileEncoder::new(&path_buf) { Ok(encoder) => encoder, <del> Err(err) => { sess.dcx().emit_err(errors::CreateNew { name, path: path_buf, err }); return; } </del> <ins> Err(err) => sess.dcx().emit_fatal(errors::CreateNew { name, path: path_buf, err }), </ins> }; write_file_header(&mut encoder, sess);

); debug!("save: data written to disk successfully"); } <del> Err((path, err)) => { sess.dcx().emit_err(errors::WriteNew { name, path, err }); } </del> <ins> Err((path, err)) => sess.dcx().emit_fatal(errors::WriteNew { name, path, err }), </ins> } }

// the global context. _timer = Some(self.sess.timer("free_global_ctxt")); if let Err((path, error)) = queries.finish() { <del> self.sess.dcx().emit_err(errors::FailedWritingFile { path: &path, error }); </del> <ins> self.sess.dcx().emit_fatal(errors::FailedWritingFile { path: &path, error }); </ins> } ret

// If we forget this, compilation can succeed with an incomplete rmeta file, // causing an ICE when the rmeta file is read by another compilation. if let Err((path, err)) = ecx.opaque.finish() { <del> tcx.dcx().emit_err(FailWriteFile { path: &path, err }); </del> <ins> tcx.dcx().emit_fatal(FailWriteFile { path: &path, err }); </ins> } let file = ecx.opaque.file(); if let Err(err) = encode_root_position(file, root.position.get()) { <del> tcx.dcx().emit_err(FailWriteFile { path: ecx.opaque.path(), err }); </del> <ins> tcx.dcx().emit_fatal(FailWriteFile { path: ecx.opaque.path(), err }); </ins> } // Record metadata size for self-profiling
Change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [fnsig] computing function signature of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --
bisects to

Discussion:
let (bounds, lifetime_bound) = self.with_dyn_type_scope(true, |this| { let bounds = this.arena.alloc_from_iter(bounds.iter().filter_map(|bound| match bound { <del> GenericBound::Trait( ty, TraitBoundModifiers { polarity: BoundPolarity::Positive | BoundPolarity::Negative(_), constness, }, ) => Some(this.lower_poly_trait_ref(ty, itctx, *constness)), // We can safely ignore constness here, since AST validation // will take care of invalid modifier combinations. GenericBound::Trait( _, TraitBoundModifiers { polarity: BoundPolarity::Maybe(_), .. }, ) => None, </del> <ins> // We can safely ignore constness here since AST validation // takes care of rejecting invalid modifier combinations and // const trait bounds in trait object types. GenericBound::Trait(ty, modifiers) => match modifiers.polarity { BoundPolarity::Positive | BoundPolarity::Negative(_) => { Some(this.lower_poly_trait_ref( ty, itctx, // Still, don't pass along the constness here; we don't want to // synthesize any host effect args, it'd only cause problems. ast::BoundConstness::Never, )) } BoundPolarity::Maybe(_) => None, }, </ins> GenericBound::Outlives(lifetime) => { if lifetime_bound.is_none() { lifetime_bound = Some(this.lower_lifetime(lifetime));

<del> #![feature(const_trait_impl)] </del> <ins> #![feature(const_trait_impl, effects)] </ins> // edition: 2021 #[const_trait]

fn main() { let _: &dyn const Trait; //~ ERROR const trait bounds are not allowed in trait object types <ins> let _: &dyn ~const Trait; //~ ERROR `~const` is not allowed here </ins> } <ins> // Regression test for issue #119525. trait NonConst {} const fn handle(_: &dyn const NonConst) {} //~^ ERROR const trait bounds are not allowed in trait object types const fn take(_: &dyn ~const NonConst) {} //~^ ERROR `~const` is not allowed here </ins>

LL |     let _: &dyn const Trait; |                 ^^^^^^^^^^^ <del> error: aborting due to 1 previous error </del> <ins> error: `~const` is not allowed here --> $DIR/const-trait-bounds-trait-objects.rs:9:17 | LL |     let _: &dyn ~const Trait; |                 ^^^^^^ | = note: trait objects cannot have `~const` trait bounds error: const trait bounds are not allowed in trait object types --> $DIR/const-trait-bounds-trait-objects.rs:14:25 | LL | const fn handle(_: &dyn const NonConst) {} |                         ^^^^^^^^^^^^^^ error: `~const` is not allowed here --> $DIR/const-trait-bounds-trait-objects.rs:16:23 | LL | const fn take(_: &dyn ~const NonConst) {} |                       ^^^^^^ | = note: trait objects cannot have `~const` trait bounds error: aborting due to 4 previous errors </ins>
Change:
This only happens with rust doc. Crate builds and runs tests successfully on current master: ICE occurs with The backtrace doesn't seem to point to any specific code in the crate. : <details<summary<strongBacktrace</strong</summary<p</p</details
I've been poking at this for a bit, and haven't really gotten a full MCVE (it still depends on (version 0.2.17) being in the dependency tree), but it's definitely much simpler.
Also, bisected this and got searched nightlies: from nightly-2023-12-14 to nightly-2023-12-15 regressed nightly: nightly-2023-12-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Minimized to:
Triage: I can no longer reproduce this. Can be closed once a regression test has been .

Discussion:
<ins> //@ check-pass // https://github.com/rust-lang/rust/issues/119792 struct Wrapper<T>(T); trait Div<Rhs> {} trait Mul<Rhs> { type Output; } impl<T> Mul<T> for Wrapper<T> { type Output = (); } impl<T> Div<Self> for Wrapper<T> {} pub trait NumOps<Rhs> {} impl<T, Rhs> NumOps<Rhs> for T where T: Mul<Rhs, Output = ()> + Div<Rhs> {} </ins>
Change:
<!-- 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. --what is weird, is that I when looking at the stacktrace, we don't seem to even reach clippy code before the crash, yet I didn't manage to reproduce this with standalone rustc :/ <!-- 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
cc just given the name of the issue

Discussion:
/// See also [`DelayDm`](rustc_error_messages::DelayDm) and [`with_no_trimmed_paths!`]. // this is pub to be able to intra-doc-link it pub fn trimmed_def_paths(tcx: TyCtxt<'_>, (): ()) -> DefIdMap<Symbol> { <del> assert!(tcx.sess.opts.trimmed_def_paths); </del> // Trimming paths is expensive and not optimized, since we expect it to only be used for error // reporting. //
Change:
This was reported on discord by who pointed out that the C++ STL has a similar issue. Example: prints: It should return success but the returned iterator will have no items. Basically if you use on a completely empty volume then it will return . Rust should interpret this as being an empty iteration and not return an error to the user. Note that empty directories do not return an error so this behaviour was overlooked. We need to add some extra logic to this : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
This is fixed in C++ STL after this PR:

Discussion:
impl Iterator for ReadDir { type Item = io::Result<DirEntry>; fn next(&mut self) -> Option<io::Result<DirEntry>> { <ins> if self.handle.0 == c::INVALID_HANDLE_VALUE { // This iterator was initialized with an `INVALID_HANDLE_VALUE` as its handle. // Simply return `None` because this is only the case when `FindFirstFileW` in // the construction of this iterator returns `ERROR_FILE_NOT_FOUND` which means // no matchhing files can be found. return None; } </ins> if let Some(first) = self.first.take() { if let Some(e) = DirEntry::new(&self.root, &first) { return Some(Ok(e));

unsafe { let mut wfd = mem::zeroed(); let find_handle = c::FindFirstFileW(path.as_ptr(), &mut wfd); if find_handle != c::INVALID_HANDLE_VALUE { Ok(ReadDir { handle: FindNextFileHandle(find_handle),

first: Some(wfd), }) } else { <del> Err(Error::last_os_error()) </del> <ins> // The status `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function // if no matching files can be found, but not necessarily that the path to find the // files in does not exist. // // Hence, a check for whether the path to search in exists is added when the last // os error returned by Windows is `ERROR_FILE_NOT_FOUND` to handle this scenario. // If that is the case, an empty `ReadDir` iterator is returned as it returns `None` // in the initial `.next()` invocation because `ERROR_NO_MORE_FILES` would have been // returned by the `FindNextFileW` function. // // See issue #120040: https://github.com/rust-lang/rust/issues/120040. let last_error = api::get_last_error(); if last_error.code == c::ERROR_FILE_NOT_FOUND { return Ok(ReadDir { handle: FindNextFileHandle(find_handle), root: Arc::new(root), first: None, }); } // Just return the error constructed from the raw OS error if the above is not the case. // // Note: `ERROR_PATH_NOT_FOUND` would have been returned by the `FindFirstFileW` function // when the path to search in does not exist in the first place. Err(Error::from_raw_os_error(last_error.code as i32)) </ins> } } }
Change:
just a minor formatting logic bug I think. If a module name is missing in the middle of a chain (here is used, but is defined) the suggestion is the full path, not just the bit in the middle that is missing. No response
looks like this was fixed already, but it's not on nightly yet (or at least, not on ) on commit I see the correct output:
seems it still not be fixed in nightly.

Discussion:
candidates .sort_by_cached_key(|c| (c.path.segments.len(), pprust::path_to_string(&c.path))); if let Some(candidate) = candidates.get(0) { <ins> let path = { // remove the possible common prefix of the path let start_index = (0..failed_segment_idx) .find(|&i| path[i].ident != candidate.path.segments[i].ident) .unwrap_or_default(); let segments = (start_index..=failed_segment_idx) .map(|s| candidate.path.segments[s].clone()) .collect(); Path { segments, span: Span::default(), tokens: None } }; </ins> ( String::from("unresolved import"), Some(( <del> vec![(ident.span, pprust::path_to_string(&candidate.path))], </del> <ins> vec![(ident.span, pprust::path_to_string(&path))], </ins> String::from("a similar path exists"), Applicability::MaybeIncorrect, )),

<ins> pub mod foo { pub mod bar { pub fn do_the_thing() -> usize { 42 } } } fn main() { println!("Hello, {}!", crate::bar::do_the_thing); //~ ERROR failed to resolve: unresolved import } </ins>

<ins> error[E0433]: failed to resolve: unresolved import --> $DIR/suggest-import-issue-120074.rs:10:35 | LL |     println!("Hello, {}!", crate::bar::do_the_thing); |                                   ^^^ unresolved import | help: a similar path exists | LL |     println!("Hello, {}!", crate::foo::bar::do_the_thing); |                                   ~~~~~~~~ help: consider importing this module | LL + use foo::bar; | help: if you import `bar`, refer to it directly | LL -     println!("Hello, {}!", crate::bar::do_the_thing); LL +     println!("Hello, {}!", bar::do_the_thing); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </ins>
Change:
has made it impossible to import some structures in when implementing dataflow analyses in external tools. When implementing for a custom dataflow problem, we can no longer import the or direction. is the source code of such an implementation. is needed to set the type of the trait. Previously, it under the export, but for now it is . The default implementation of the , so I can simply use the default value as a workaround. However, if I need to write a backward analysis, I must rewrite some parts of the framework in our source code because they cannot be imported. There are other tools in the ecosystem that use that API, e.g.: These changes will make problems if they decide to update to the recent toolchain. Could you please take a look at this matter? Are these changes intentional? Could we make some of the exports public again? cc
Feel free to send in a PR to make it public again. Please add a comment on the items saying they're used by external tools.
I will double-check which of the removed imports might be beneficial for external tools and will send a PR if there are no objections.

Discussion:
use rustc_middle::ty; <ins> // Please change the public `use` directives cautiously, as they might be used by external tools. // See issue #120130. </ins> pub use self::drop_flag_effects::{ drop_flag_effects_for_function_entry, drop_flag_effects_for_location, move_path_children_matching, on_all_children_bits, on_lookup_result_bits, }; pub use self::framework::{ <del> fmt, lattice, visit_results, Analysis, AnalysisDomain, Direction, GenKill, GenKillAnalysis, JoinSemiLattice, MaybeReachable, Results, ResultsCursor, ResultsVisitable, ResultsVisitor, </del> <ins> fmt, graphviz, lattice, visit_results, Analysis, AnalysisDomain, Backward, Direction, Engine, Forward, GenKill, GenKillAnalysis, JoinSemiLattice, MaybeReachable, Results, ResultsCursor, ResultsVisitable, ResultsVisitor, SwitchIntEdgeEffects, </ins> }; <del> use self::framework::{Backward, SwitchIntEdgeEffects}; </del> use self::move_paths::MoveData; pub mod debuginfo;
Change:
When setting (for x.py) to a path that doesn't end in a file named (or ) the test fails, due to explicitly asserting that the config file has one of these names (test is ) This could be indicitive of a larger issue, as which is used in many bootstrap tests seems to rely on a concerning amount of external state (this could cause more issues in the future if not resolved, and/or make bootstrap's tests fail when a users config is invalid) If this behavior is intentional, there is a bug in , because the sets which triggers this bug Alternately, could emit an error if RUSTBOOTSTRAPCONFIG is set to an invalid path, with a suggestion on how to fix it (though this seems like a questionable fix) label +C-bug +T-bootstrap
if is accepted, this would be somewhat lower priority (though not fixed)
No, it's not. It's just a logical bug in the test that I will fix quickly.

Discussion:
#[test] fn profile_user_dist() { fn get_toml(file: &Path) -> TomlConfig { <del> let contents = if file.ends_with("config.toml") { "profile = "user"".to_owned() } else { assert!(file.ends_with("config.dist.toml")); std::fs::read_to_string(file).unwrap() }; </del> <ins> let contents = if file.ends_with("config.toml") || env::var_os("RUST_BOOTSTRAP_CONFIG").is_some() { "profile = "user"".to_owned() } else { assert!(file.ends_with("config.dist.toml")); std::fs::read_to_string(file).unwrap() }; </ins> toml::from_str(&contents) .and_then(|table: toml::Value| TomlConfig::deserialize(table)) .unwrap()
Change:
I think that and conditions should free any temporaries that occur within them (for conditions it's mandatory, actually, since the condition is evaluated many times). That is, if I write: the temporary returned by should be freed once the condition is evaluated, before entering the body of the . The same holds for . What makes these expressions different from other compound forms is that the conditions are evaluated to scalar booleans, and hence can never create lasting aliases that might need to be preserved. In the case of a while, this is needed because temporaries can never outlive conditional or repeated scopes, and the condition of a while is a repeated scope.
cc
Marking as mentor with myself. This is a fairly small change (if you know what to change :)
I'll work on it :)
0 blocker, P-backcompat-lang.
The fix in was partial, with an is still broken:
Nominated. Seems clear to me that this is a bug we should fix -- the main question is whether to be concerned about backwards compatibility, and -- if so -- what to do about it. I think this is mostly a question for team to decide, but I tagged this issue with T-Lang too in case members want to weight in on whether the behavior is indeed a bug. But it seems clear that having and behave differently is bogus.
Consensus in the compiler team meeting was that we should just fix this and add the resulting PR to the release notes. triage: P-medium

Discussion:
visitor.region_maps.mark_as_terminating_scope(otherwise.id); } <del> ast::ExprIf(_, then, None) => { </del> <ins> ast::ExprIf(expr, then, None) => { visitor.region_maps.mark_as_terminating_scope(expr.id); </ins> visitor.region_maps.mark_as_terminating_scope(then.id); } <del> ast::ExprLoop(body, _) | ast::ExprWhile(_, body) => { </del> <ins> ast::ExprLoop(body, _) => { visitor.region_maps.mark_as_terminating_scope(body.id); } ast::ExprWhile(expr, body) => { visitor.region_maps.mark_as_terminating_scope(expr.id); </ins> visitor.region_maps.mark_as_terminating_scope(body.id); }

<ins> // Copyright 2014 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. // This test verifies that temporaries created for `while`'s // and `if` conditions are correctly cleaned up. struct Temporary; static mut DROPPED: int = 0; impl Drop for Temporary { fn drop(&mut self) { unsafe { DROPPED += 1; } } } impl Temporary { fn do(&self) -> bool {true} } fn borrow() -> ~Temporary { ~Temporary } pub fn main() { let mut i = 0; // This loop's condition // should call `Temporary`'s // `drop` 6 times. while borrow().do() { i += 1; if i > 5 { break; } } // This if condition should // call it 1 time if borrow().do() { unsafe { assert_eq!(DROPPED, 7) } } } </ins>
Change:
Seems like the updated test expectations don't quite match up with LLVM 18, first failing check is: Found over at our experimental rust + LLVM @ HEAD build bot: Looks like LLVM 18 adds some extra -s, testing a PR to fix this:
label: +A-LLVM

Discussion:
#[no_mangle] pub fn a(exp: u32) -> u64 { // CHECK: %{{[^ ]+}} = icmp ugt i32 %exp, 64 <del> // CHECK: %{{[^ ]+}} = zext i32 %exp to i64 </del> <ins> // CHECK: %{{[^ ]+}} = zext{{( nneg)?}} i32 %exp to i64 </ins> // CHECK: %{{[^ ]+}} = shl nuw i64 {{[^ ]+}}, %{{[^ ]+}} // CHECK: ret i64 %{{[^ ]+}} 2u64.pow(exp)

#[no_mangle] pub fn b(exp: u32) -> i64 { // CHECK: %{{[^ ]+}} = icmp ugt i32 %exp, 64 <del> // CHECK: %{{[^ ]+}} = zext i32 %exp to i64 </del> <ins> // CHECK: %{{[^ ]+}} = zext{{( nneg)?}} i32 %exp to i64 </ins> // CHECK: %{{[^ ]+}} = shl nuw i64 {{[^ ]+}}, %{{[^ ]+}} // CHECK: ret i64 %{{[^ ]+}} 2i64.pow(exp)
Change:
Apologies if this isn't the right place, it isn't obvious to me if this originates in rustc or should be upstreamed to FreeBSD. My limited understand of the warnings however suggests it could be a misuse of s on our end. The following comment from seems relevant: I can't reproduce this on latest stable, just latest nightly so far.
Bisected with : regressed nightly: nightly-2024-01-24 searched commit range: regressed commit: I think it is probably ( which is awkward because all that change did was enable thread-local support on FreeBSD.
Can reproduce too, however no problem on netbsd (reading ). It might be valuable to get an insight of what might happen in the system side of things.
Rustc doesn't dlclose any of the libraries it dlopen's. And if you don't use proc macros or a codegen backend other than the default LLVM, it doesn't dlopen any library.
ktrace for the curious: <details<summarykdump</summary</details

Discussion:
target_os = "fuchsia", target_os = "redox", target_os = "hurd", <del> target_os = "freebsd", </del> target_os = "netbsd", target_os = "dragonfly" ))]

target_os = "vxworks", target_os = "horizon", target_os = "emscripten", <del> target_os = "aix" </del> <ins> target_os = "aix", target_os = "freebsd", </ins> ))] #[cfg_attr(target_family = "wasm", allow(unused))] // might remain unused depending on target details (e.g. wasm32-unknown-emscripten) pub unsafe fn register_dtor(t: *mut u8, dtor: unsafe extern "C" fn(*mut u8)) {