jiebi/CodeConvo huggingface dataset:
Change:
LookupResult::Parent(Some(parent)) => { let (_maybe_live, maybe_dead) = self.init_data.maybe_live_dead(parent); if maybe_dead { <del> span_bug!( </del> <ins> self.tcx.sess.delay_span_bug( </ins> terminator.source_info.span, <del> "drop of untracked, uninitialized value {:?}, place {:?} ({:?})", bb, place, path </del> <ins> &format!( "drop of untracked, uninitialized value {:?}, place {:?} ({:?})", bb, place, path, ), </ins> ); } continue;

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. --The panic happens here <!-- 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
I can't seem to reproduce this locally, does it go away if you update your compiler?
Current compiler is: rustc 1.57.0 ( 2021-11-29) And the same happens when I use beta and nightly: beta: cargo 1.56.0-beta ( 2021-09-01) nightly: cargo 1.57.0-nightly ( 2021-09-18) I remembered I was using mold linker () but I switched to the default linker and the same happens, other then that my setup is normal
Actually I can confirm its reproducible, I just tried it with and the same thing happens maybe you didn't checkout the ice branch?
Ahhh, oops. Didn't notice it was on a different branch. Sorry, my bad! Yes, I can reproduce it fine locally.
MCVE: This code has move errors and fails const-checking, just like the original example. The ICE occurs after errors are emitted. did you truncate the logs in your original post? One option is to change the following statement to : For the non-const version, we abort before we ever get to drop elaboration due to the errors, though I'm not sure why.
For const items is queried earlier, without an intermediate exit point:
yes the error log is truncated, I have a move error

<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.
Change:
/// Creates a new hasher. /// <ins> /// Each call to `build_hasher` on the same instance should produce identical /// [`Hasher`]s. /// </ins> /// # Examples /// /// ```

Discussion:
Part of Here's what needs to be done to close out this issue: needs a stronger summary/explanation distinction. "This structure is zero-sized and does not need construction." is weird. also needs a stronger summary/explanation distinction. It also needs a better explanation of why it exists with an example. needs general improvement, it is the main bit of this module, but its docs feel tossed together and have few examples or coherence. needs more than just a summary line; it needs explanation and examples.
What kind of further documentation are you looking for here?
Better explanations for examples of implementing and and and more docs generally for all three.
There seem to be a lengthy example of BuildHasherDefault in this commit () Also for BuildHasher and there is a healthy amount of documentation as of now. Hasher seems to be really outdated (still lists several Implementors without mentioning they have been deprecated), which I'm looking into right now.
Thanks ! Looks like all that's left is documenting .
I am happy to mentor anyone who wants to tackle this issue.
I volunteer as a tribute :-)
wonderful! If you need any help, please just let me know, as I said above, happy to help you help me (We can do it here or ping me on IRC)
I have more specifics in the main issue above
I'm gonna tackle this one this weekend! (if that's okay with you,
Change:
<ins> // This test contains code with incorrect vtables in a const context: // - from issue 86132: a trait object with invalid alignment caused an ICE in const eval, and now //   triggers an error // - a similar test that triggers a previously-untested const UB error: emitted close to the above //   error, it checks the correctness of the size trait Trait {} const INVALID_VTABLE_ALIGNMENT: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: alignment `1000` is not a power of 2 const INVALID_VTABLE_SIZE: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: size is bigger than largest supported object fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
((0, 0) | (1, 0),) => {} _ => {} } <ins> // This one caused ICE https://github.com/rust-lang/rust/issues/117378 match (0u8, 0) { (x @ 0 | x @ (1 | 2), _) => {} (3.., _) => {} } </ins> }

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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
cc
Oh I see, nested or-patterns are usually flattened except not here because of the bindings! Fix incoming, thanks again
Change:
/// Returns the value as a primitive type. #[stable(feature = "nonzero", since = "1.28.0")] #[inline] <del> pub fn get(self) -> $Int { </del> <ins> pub const fn get(self) -> $Int { </ins> self.0 }

Discussion:
and undo the const -fn changes in This requires changing applicable methods on from to , adding the attribute to all of them and adding some tests ensuring that the methods are not const fn on stable rust.
Ah, no, it requires conditional control-flow.
Ah I thought there were more trivial methods. This issue is only acctionable for at the moment
Hi, I'd like to help out on this. I would appreciate if some one gave me pointers on what needs to be accomplished.
Steps: to the attribute a test in that shows a const usage of the method (needs the feature gate specified in whether the linked commit above can be partially reverted
you may take a look at . These are the steps you have to do in order to add .
I will do that sir. Was busy with my internship.
If you need help, don't hesitate to ping me here, in Discord (Cyres) or on in the rust chat room.
Thank you
Change:
<ins> pub mod unix { #[allow(non_camel_case_types)] pub type pid_t = i32; pub fn get_pid() -> pid_t { 0 } pub fn set_pid(_: pid_t) {} } </ins>

Discussion:
The "In Names" search tab is fine, but the "In Parameters" and "In Return Types" have the confusing note that ! label: +T-rustdoc +A-rustdoc-ui
Change:
#![feature(box_into_raw_non_null)] #![feature(box_patterns)] #![feature(box_syntax)] <ins> #![feature(cfg_sanitize)] </ins> #![feature(cfg_target_has_atomic)] #![feature(coerce_unsized)] #![feature(const_generic_impls_guard)]

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.
Change:
} if is_diagnostic_namespace_variant { <del> tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), vec![item.span()], MalformedOnUnimplementedAttrLint::new(item.span()), ); </del> <ins> if let Some(def_id) = item_def_id.as_local() { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(def_id), vec![item.span()], MalformedOnUnimplementedAttrLint::new(item.span()), ); } </ins> } else { // nothing found tcx.dcx().emit_err(NoValueInOnUnimplemented { span: item.span() });

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. --The simplest version uses / however I have also tested this via a sub-crate. : : <!-- 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. --: I can also reproduce this on and on and . When running <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Change:
fn recovery() -> Recovery { Recovery::Forbidden } <ins> fn set_expected_token(&mut self, _tok: &'matcher Token) {} fn get_expected_token(&self) -> Option<&'matcher Token> { None } </ins> } /// A noop tracker that is used in the hot path of the expansion, has zero overhead thanks to

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> Subproject commit af078ecc0b069ec594982f92d4c6c58af99efbb5 </del> <ins> Subproject commit 710fc18ddcb6c7677b3c96359abb35da37f2a488 </ins>

Discussion:
When panicking, every line of stack traces contain instead of a code location. E.g. I'm on rustc 1.47.0 and FreeBSD 12.1: Possible duplicate of I've tried mounting /proc but it didn't fix the problem.
Can you test on old Rust stable version to see if this is a regression ? Edit: This is an expected regression
It worked on 1.46.0:
Do you know if there is a build farm for freebsd like gcc build farm ? Because we could fo find from which PR caused the regression. Otherwise, since freebsd is a tier-2 target, not everyone could investigate it. modify labels: T-compiler
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .) and removing .
For what it's worth, this problem occurs on iOS (x86_64-apple-ios) builds too: 1.47.0: 1.46.0:
Likely caused by . (switching from libbacktrace to gimli) It seems that is not implemented for FreeBSD: I think this means that it can't find the debuginfo for any libraries and the current executable.
For iOS it may or may not work to extend the condition at to include iOS too.
You're right! I submitted a PR to fix it for iOS. Thanks a lot!
You might want to file another PR to update backtrace-rs submodule in this repo.
Thanks!
It looks like , so I think we could just extend to cover FreeBSD
Hi, could you ( or ) use rustup- toolchain-install-master to install and try this build: for freebsd?
Looks good!
backtrace-rs issue: backtrace-rs PR for issue:
What's left to do here? Would a PR that updates the submodule for library/backtrace be sufficient?
Change:
<ins> { "llvm-target": "x86_64-unknown-none-gnu", "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", "arch": "x86_64", "target-endian": "little", "target-pointer-width": "64", "target-c-int-width": "32", "os": "ericos", "linker-flavor": "ld.lld", "linker": "rust-lld", "executables": true } </ins>

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
test_transparent!(unit, ()); test_transparent!(pair, (i32, f32)); // mixing in some floats since they often get special treatment test_transparent!(triple, (i8, i16, f32)); // chosen to fit into 64bit <ins> test_transparent!(triple_f32, (f32, f32, f32)); // homogeneous case test_transparent!(triple_f64, (f64, f64, f64)); </ins> test_transparent!(tuple, (i32, f32, i64, f64)); test_transparent!(empty_array, [u32; 0]); test_transparent!(empty_1zst_array, [u8; 0]);

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
<del> Subproject commit 3a37981744a5af2433fed551f742465c78c9af7f </del> <ins> Subproject commit b5ac4cd44321da10dfd70f070dbc9094ca3f92ff </ins>

Discussion:
The new installer has a bug that causes the docs to be installed in a way that can't be read by non-root.
This is because the docs in-tree have non-world-readable permissions. I think we'll need a build step that just changes the permissions of everything in the doc directory.
Actually, I'm going to fix this in rust-installer.
Fixed in
Change:
let some_str: Option<&'static str> = Some("abc"); let none_str: Option<&'static str> = None; <del> let some: Option<&u32> = Some(unsafe { std::mem::transmute(0x12345678_usize) }); </del> <ins> let some: Option<&u32> = Some(&1234); </ins> let none: Option<&u32> = None; <del> let full = MoreFields::Full(454545, unsafe { std::mem::transmute(0x87654321_usize) }, 9988); </del> <ins> let full = MoreFields::Full(454545, &1234, 9988); </ins> let empty = MoreFields::Empty; <del> let empty_gdb: &MoreFieldsRepr = unsafe { std::mem::transmute(&MoreFields::Empty) }; </del> let droid = NamedFields::Droid { id: 675675, range: 10000001, <del> internals: unsafe { std::mem::transmute(0x43218765_usize) } </del> <ins> internals: &1234, </ins> }; let void_droid = NamedFields::Void; <del> let void_droid_gdb: &NamedFieldsRepr = unsafe { std::mem::transmute(&NamedFields::Void) }; let x = 'x'; </del> let nested_non_zero_yep = NestedNonZero::Yep( 10.5, NestedNonZeroField { a: 10, b: 20, <del> c: &x </del> <ins> c: &'x', </ins> }); let nested_non_zero_nope = NestedNonZero::Nope; zzz(); // #break

Discussion:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.
Change:
# The "channel" for the Rust build to produce. The stable/beta channels only # allow using stable features, whereas the nightly and dev channels allow using # nightly features <del> #channel = "dev" </del> <ins> # # If using tarball sources, default value for `channel` is taken from the `src/ci/channel` file; # otherwise, it's "dev". #channel = if "is a tarball source" { content of `src/ci/channel` file } else { "dev" } </ins> # A descriptive string to be appended to `rustc --version` output, which is # also used in places like debuginfo `DW_AT_producer`. This may be useful for

Discussion:
On current master: Same thing on the 1.80.0 release tag: This default value of "dev" used to be accurate prior to , i.e. with Rust 1.79 and older. The default value comes from this hardcoded value: But post-, the default value varies by how you got your source tarball, or what git branch you are on. It is not accurate for the Rust 1.80.0 release sources to say the default value for is "dev", as it's actually "stable" now. Mentioning since you worked on the PR (which I am otherwise happy with). The change in default also needs to be called out in
Change:
if self.tcx.is_thread_local_static(def_id) { self.tcx.dcx().span_bug(span, "tls access is checked in `Rvalue::ThreadLocalRef`"); } <ins> if let Some(def_id) = def_id.as_local() && let Err(guar) = self.tcx.at(span).check_well_formed(hir::OwnerId { def_id }) { self.error_emitted = Some(guar); } </ins> self.check_op_spanned(ops::StaticAccess, span) }

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. --(reduced) <details<summary<strongOriginal</strong</summary<p</p</details<!-- 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
Bisects to , but I guess it just made the ICE easier to reach. cc
Nope unfortunately this one only reproduces with statics, and thus can't be reached on stable or before that PR. It's still not useful to look at to figure out why it's ICEing now, as the ICE is happening somewhere else entirely.
Change:
<ins> // run-pass // aux-build:tokyo.rs // compile-flags:--extern tokyo // edition:2021 use tokyo::main; #[main] fn main() { panic!("the #[main] macro should replace this with non-panicking code") } </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 an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Change:
rustc } else { config.download_beta_toolchain(); <del> config.out.join(config.build.triple).join("stage0/bin/rustc") </del> <ins> config .out .join(config.build.triple) .join("stage0") .join("bin") .join(exe("rustc", config.build)) </ins> }; config.initial_cargo = if let Some(cargo) = cargo {

Discussion:
I tried this with Rust 1.66.0, simplified from my build for Fedora: I expected to see this happen: passing tests Instead, this happened: 20 failures, all of this sort: My stage0 should be using . It most recently worked on: Rust 1.65.0 : I bisected this to , commit , which stopped using and environment variables when building a . <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged +A-bootstrap <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI we had the same problem on Debian, worked around with a custom patch:
Change:
<ins> // compile-pass static mut STDERR_BUFFER_SPACE: [u8; 42] = [0u8; 42]; pub static mut STDERR_BUFFER: *mut [u8] = unsafe { &mut STDERR_BUFFER_SPACE }; fn main() {} </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
assert_eq!(res, "$ORIGIN/../lib"); } } <ins> #[test] fn test_xlinker() { let args = rpaths_to_flags(&[ "a/normal/path".to_string(), "a,comma,path".to_string() ]); assert_eq!(args, vec![ "-Wl,-rpath,a/normal/path".to_string(), "-Wl,-rpath".to_string(), "-Xlinker".to_string(), "a,comma,path".to_string() ]); } </ins> }

Discussion:
generates linker options of the form . This fails if contains commas, because separates options on commas, so the linker ends up getting a bad path and spurious extra parameters. The solution is to use which passes the next option through literally, so the full rpath can be specified with . The form is fairly verbose, and only needed when there are commas. (This comes up when building with , because it generates paths of the form where "flavors" are things like "shared", "static", "pic", etc.)
Fixed in 1.16