jiebi/CodeConvo huggingface dataset:
Change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/11.0-2020-10-12 </del> <ins> branch = rustc/11.0-2021-01-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

Discussion:
Code: Output in release mode: There is a similar issue about , but incorrect comparison of may be more dangerous. For example, if unsafe code checks the equality between to uphold its invariant, passing values obtained this way may break the invariant, even though the unsafe code itself didn't work with function pointers.
In some sense there's no bug here, this is expected: comparing function pointers should behave the same with or without the cast. What is more surprising is that they print the same. This indicates that comparison is non-deterministic... which is rather problematic indeed, and could break plenty of LLVM optimizations.
Indeed this can be turned into a demonstration of non-deterministic comparison: The second assertion fails, the first passes (in release mode on 1.45.2). That's no good. In principle this could lead to a soundness bug, though I am not sure if that can be actually done in practice. Cc
This is an LLVM bug:
But MIR optimizations also have to be aware that folding equality tests on functions is subtle (Cc And recently had to prevent me from making a similar mistake for pointer equality tests in CTFE (Cc
The LLVM bug has been fixed. (pinging you in lieu of there being a way to ping the LLVM WG), do you usually backport such fixes or wait for the next release?
cc (pinging LLVM WG) I suspect we'll want to backport the patch ourselves, and try to nominate it for LLVM 11 (since that's not yet released, and we're currently on a release candidate). is the thing to backport I think.
Assigning as discussed as part of the and removing .
Discussion on the LLVM bug is that it's too late for 11.0.0, but could be to 11.0.1. If someone wants to see the fix sooner in rust's fork, I'm happy to review PRs: https://rustc-dev-
Change:
target.GetBroadcaster().AddListener(listener, lldb.SBTarget.eBroadcastBitBreakpointChanged) <ins> def start_watchdog(): "Starts a watchdog thread that will terminate the process after a certain period of time" watchdog_start_time = time.clock() watchdog_max_time = watchdog_start_time + 30 def watchdog(): while time.clock() < watchdog_max_time: time.sleep(1) print("TIMEOUT: lldb_batchmode.py has been running for too long. Aborting!") thread.interrupt_main() # Start the listener and let it run as a daemon watchdog_thread = threading.Thread(target = watchdog) watchdog_thread.daemon = True watchdog_thread.start() </ins> #################################################################################################### # ~main ####################################################################################################

Discussion:
From time to time the LLDB test suite hangs on the build bots, which leads to the whole pipeline being blocked for an hour. One way to make this problem a bit less severe is to add a time-out to the LLDB test runner which just kills tests that take longer than a few seconds. This should at least reduce the time until the tests can be restarted. cc
cc
Change:
pub static mut A: u32 = 0; pub static mut B: () = unsafe { A = 1; }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR could not evaluate static initializer </ins> pub static mut C: u32 = unsafe { C = 1; 0 }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR cycle detected </ins> pub static D: u32 = D;

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:
<del> Subproject commit c0f39cfb466202a1dbe8368ca177848083dc34cb </del> <ins> Subproject commit ea85b4c7fb9826f72bd4ab743a703a34c75a40f0 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
.filter(|dep| dep.source.is_none()) .map(|dep| INTERNER.intern_string(dep.name)) .collect(); <del> build.crates.insert(name, Crate { name, deps, path }); </del> <ins> let krate = Crate { name, deps, path }; let relative_path = krate.local_path(build); build.crates.insert(name, krate); let existing_path = build.crate_paths.insert(relative_path, name); assert!(existing_path.is_none(), "multiple crates with the same path"); </ins> } } }

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
<del> Subproject commit ece09b88c0365947af79c0ffdeea02bc6c1eec25 </del> <ins> Subproject commit fcf1f94c9ab2acc18cfd4368a4aeb38e77da9649 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Yes, I think I'll have time to fix this today.
I think there are other changes that need to happen first. I tried to compile with tonight's nightly and got lots of errors from rustfmt: do you know what could be going wrong? do I need to update rustfmt or something like that?
I pushed the latest update at is the failure above from the build here or in the RLS repo? Rustfmt should be vendored here and should work as expected IIUC.
that's in the RLS repo.
Change:
<ins> // Regression test for issue 111184, where ty::GeneratorWitness were not expected to occur in // encode_ty and caused the compiler to ICE. // // needs-sanitizer-cfi // compile-flags: -Clto -Ctarget-feature=-crt-static -Zsanitizer=cfi --edition=2021 // no-prefer-dynamic // only-x86_64-unknown-linux-gnu // run-pass use std::future::Future; async fn foo() {} fn bar<T>(_: impl Future<Output = T>) {} fn main() { bar(foo()); } </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 --
claim
Change:
let has_hwasan = util::HWASAN_SUPPORTED_TARGETS.contains(&&*config.target); let has_memtag = util::MEMTAG_SUPPORTED_TARGETS.contains(&&*config.target); let has_shadow_call_stack = util::SHADOWCALLSTACK_SUPPORTED_TARGETS.contains(&&*config.target); <del> // for `-Z gcc-ld=lld` </del> <ins> // For tests using the `needs-rust-lld` directive (e.g. for `-Zgcc-ld=lld`), we need to find // whether `rust-lld` is present in the compiler under test. // // The --compile-lib-path is the path to host shared libraries, but depends on the OS. For // example: // - on linux, it can be <sysroot>/lib // - on windows, it can be <sysroot>/bin // // However, `rust-lld` is only located under the lib path, so we look for it there. </ins> let has_rust_lld = config .compile_lib_path <ins> .parent() .expect("couldn't traverse to the parent of the specified --compile-lib-path") .join("lib") </ins> .join("rustlib") .join(&config.target) .join("bin") <del> .join("gcc-ld") .join(if config.host.contains("windows") { "ld.exe" } else { "ld" }) </del> <ins> .join(if config.host.contains("windows") { "rust-lld.exe" } else { "rust-lld" }) </ins> .exists(); iter_header(path, src, &mut |revision, ln| { if revision.is_some() && revision != cfg { return;

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: and this happened: I expected to see this happen: it would compile my crate. Instead, this happened: lld failed. <!-- 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. --: fixed the problem that I reported in There seems to be a new problem with an unknown linker name. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Could you post the list of files in the directory in Rust distribution?
I found in the clang invocation:
It looks like maybe clang replaces and changes it from to when calling lld-wrapper?
I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the alternative to in lld-wrapper.
Apple ships its linker as . I couldn't find a file.
I believe the issue is with the usage of in the PR, see: You probably meant to use . Wait. is because of Windows? is the only one that does not play well with it. One solution is to normalise the string or before the match statement.
This is not happening only on osx. I can reproduce this. The path is correct and unchanged by clang, but it's indeed the call that trims too much on unixes because of the weird executable name with a dot. I'll fix it.
The problem still exists, but the error changed to on macos. Need more investigation..
Change:
<ins> macro_rules! suite { ( $( $fn:ident; )* ) => { $( const A = "A".$fn(); //~^ ERROR the name `A` is defined multiple times //~| ERROR missing type for `const` item //~| ERROR the type placeholder `_` is not allowed within types )* } } suite! { len; is_empty; } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
I ran : That's a rollup commit. Of the components of the rollup, looks to me to be most likely to be related. (cc
Hmm, bummer. It looks like they are getting the same span and so the stashed error is overwritten. We might need to insert a there to handle the possibility of span reuse from different things.
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
Fixed in
Change:
<ins> // run-pass use std::ptr::addr_of; // When the unsized tail is a `dyn Trait`, its alignments is only dynamically known. This means the // packed(2) needs to be applied at runtime: the actual alignment of the field is `min(2, // usual_alignment)`. Here we check that we do this right by comparing size, alignment, and field // offset before and after unsizing. fn main() { #[repr(C, packed(2))] struct Packed<T: ?Sized>(u8, core::mem::ManuallyDrop<T>); let p = Packed(0, core::mem::ManuallyDrop::new(1)); let p: &Packed<usize> = &p; let sized = (core::mem::size_of_val(p), core::mem::align_of_val(p)); let sized_offset = unsafe { addr_of!(p.1).cast::<u8>().offset_from(addr_of!(p.0)) }; let p: &Packed<dyn Send> = p; let un_sized = (core::mem::size_of_val(p), core::mem::align_of_val(p)); let un_sized_offset = unsafe { addr_of!(p.1).cast::<u8>().offset_from(addr_of!(p.0)) }; assert_eq!(sized, un_sized); assert_eq!(sized_offset, un_sized_offset); } </ins>

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
displayName: "Ensure build happens on C:/ instead of D:/" condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) <ins> - bash: git config --replace-all --global core.autocrlf false displayName: "Disable git automatic line ending conversion (on C:/)" </ins> # Download and install MSYS2, needed primarily for the test suite (run-make) but # also used by the MinGW toolchain for assembling things. #

Discussion:
Since the change from travis to azure pipelines some of the rust-std archives have DOS line endings in their script, which results in errors like the following when trying to execute: Running works around the issue for now. Not all archives have this issue. Specifically does. Possibly others as well, but our install process fails after the first error, so I am not sure. See mattgodbolt/compiler-explorer-image and mattgodbolt/compiler-explorer-image
Thanks for reporting this! A tentative fix for this landed in , hopefully tomorrow's nightlies will be fixed.
Still happening on :/
Oh, this is concerning, we'll need to look into it a bit more. Thanks for the update. modify labels: regression-from-stable-to-beta -regression-from-stable-to-nightly
May have been actually .. Double checking.
is also affected, does that mean src is now generated from Windows or this is broken even more than it seems?
This is caused by the Azure migration, as it started happening right after we switched nightlies production to it. The initial hypothesis was that git's on Windows was the culprit, but that landed days ago so we need to look deeper :/
The source tarball is generated by all the dist builders and uploaded each time, so the last dist builder to finish will be the one producing the final tarball. I think we see the error there just because our slower builders are all Windows at the moment.
Assigning myself to investigate in the next few days.
Relevant: https://git-
The fix should've landed in today's nightly. Thanks everyone for reporting this!
Just a note, you might want to spin up a beta build as well. was affected by this as well.
yes, beta is still not fixed. The fix was nominated for beta backport though, so once the team approves we will backport it to the beta branch.
We backported the change!
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] type T = impl Sized; // The concrete type referred by impl-trait-type-alias(`T`) is guaranteed // to be the same as where it occurs, whereas `impl Trait`'s instance is location sensitive; // so difference assertion should not be declared on impl-trait-type-alias's instances. // for details, check RFC-2515: // https://github.com/rust-lang/rfcs/blob/master/text/2515-type_alias_impl_trait.md fn take(_: fn() -> T) {} fn main() { take(|| {}); take(|| {}); } </ins>

Discussion:
Version: The second function call is necessary. It will compile and run just fine with only one call. Output:
This may be irrelevant to async-await, as we can replace with any trait and still reproduces:
Change:
// Check if we have an enum variant. let mut variant_resolution = None; <del> if let ty::Adt(adt_def, _) = qself_ty.kind() { </del> <ins> if let ty::Adt(adt_def, adt_substs) = qself_ty.kind() { </ins> if adt_def.is_enum() { let variant_def = adt_def .variants()

Discussion:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.
Change:
<ins> // no-prefer-dynamic #![feature(lang_items)] #![crate_type = "rlib"] #![no_std] pub struct DerefsToF64(f64); impl core::ops::Deref for DerefsToF64 { type Target = f64; fn deref(&self) -> &Self::Target { &self.0 } } mod inner { #[lang = "f64_runtime"] impl f64 { /// [f64::clone] pub fn method() {} } } #[lang = "eh_personality"] fn foo() {} #[panic_handler] fn bar(_: &core::panic::PanicInfo) -> ! { loop {} } </ins>

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
<ins> #![crate_type = "cdylib"] #[no_mangle] extern "C" fn foo() {} </ins>

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
Change:
#[inline(always)] fn enforce_alignment(ecx: &InterpCx<'mir, 'tcx, Self>) -> bool { <del> ecx.tcx.sess.opts.unstable_opts.extra_const_ub_checks </del> <ins> ecx.machine.check_alignment </ins> } #[inline(always)]

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
} /// Returns the next token, including trivia like whitespace or comments. <del> pub fn next_token(&mut self) -> Token { </del> <ins> fn next_token(&mut self) -> Token { </ins> let start_src_index = self.src_index(self.pos); let text: &str = &self.src[start_src_index..self.end_src_index];

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C no-prepopulate-passes struct Foo; impl Foo { // CHECK: define internal x86_stdcallcc void @{{.*}}foo{{.*}}() #[inline(never)] pub extern "stdcall" fn foo<T>() { } } fn main() { Foo::foo::<Foo>(); } </ins>

Discussion:
rustc 1.7.0 ( 2016-02-29) (32-bit GNU) rustc 1.9.0-nightly ( 2016-03-17) (32-bit MSVC)
This was fixed by , methods' ABIs were previously completely ignored.
Yes, rustc 1.9.0-nightly ( 2016-03-21) (32-bit MSVC) is working fine. Thanks.
I'd like this open to make sure a test ends up being written.
Change:
} /// Computes a place. You should only use this if you intend to write into this <del> /// place; for reading, a more efficient alternative is `eval_place_for_read`. </del> <ins> /// place; for reading, a more efficient alternative is `eval_place_to_op`. </ins> #[instrument(skip(self), level = "debug")] pub fn eval_place( &mut self,

Discussion:
Hello, It feels like this shouldn't be an issue but I don't really know where to post it otherwise.. says that there is a more efficient solution when the place is access for read called , but the latter does not exist anywhere. I'm guessing it should be referring to , but I am not entirely sure. Also as a side question, I'd be curious to know why it is slower to access a place for write than it is for read. I'm going to spend a bit of time reading that part of the code, if I ever find other tiny things like that, where should I report it ? It feels like this could be a small discussion in a chat followed by a tiny PR rather than an issue. Thank you ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If you have a question while making a PR, on good resource is Zulip: https://rust- Depending how easy a PR it is and whether you're reasonably confident in your deduction, you could also just make a PR changing it and the reviewer will confirm that the update is accurate.
Your analysis looks correct to me. I'm working up a PR to fix these docs. claim
Issues like this are welcome, as are small PRs. :)