jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // revisions:rpass1 rpass2 struct A; #[cfg(rpass2)] impl From<A> for () { fn from(_: A) {} } fn main() {} </ins>

Related discussion:
text: For the first question: I am on windows 10 Pro 1809, CPU 1950X, 64 GB RAM and steps to reproduce are simple for me: start IntelliJ IDEA new rust project to add replace withbuild add as mentioned above build ~50% chance it fail if the build worked just rename build failed 5 of 6 times I get that far without deleting folder For the second question yes it started recently when I tried this crate, but more importantly the issue persisted after I removed it, it is just much less common than every second build.
Sadly I cannot reproduce it. Let me try to summarize it: as dependency in (hope it crashes) not, use Am I correct? Please be as precice as possible and clarify "just rename ". Do you want me to change lower/upper case? Remove one character? Add one? Your nightly seems kind of outdated. Is it still possible for you if you use the latest nightly? (I tried both, no luck)
It seems that it has been fixed on latest nightly, but I'm now able to reproduce it 100% with nightly-2019-04-05 (). new project as dependency in build in front of build in front of again
I would suggest to remove the P-High and I-nomiated tag, because it is fixed on nightly. I'll add the E-needstest tag. I just have to reduce the above example without external dependencies. Lets see what I can do. modify labels: E-needstest
Thanks a lot for looking into this, can you confirm that the crash doesn't occur anymore with the latest nightly compiler?
After a lot of effort I switched toolchain to and it seems to work here (over 20 rebuilds without error)
please do not close this issue. I created a PR which will automatically close this when it has been merged. Please reopen it
This is likely caused by and fixed by
Can confirm that the bug has been fixed in (bisecting ftw)
Code change:
} /// Builds drops for pop_scope and exit_scope. <del> fn build_scope_drops<'tcx>(mut block: BasicBlock, </del> <ins> fn build_scope_drops<'tcx>(cfg: &mut CFG<'tcx>, </ins> scope: &Scope<'tcx>, earlier_scopes: &[Scope<'tcx>], <del> cfg: &mut CFG<'tcx>) </del> <ins> mut block: BasicBlock) </ins> -> BlockAnd<()> { let mut iter = scope.drops.iter().rev().peekable(); while let Some(drop_data) = iter.next() {

Related discussion:
text: This generates the following (broken) MIR: As you can see, is dropped but never written to (AFAIK this should be OK because of zeroing) but the boxes are never freed.
cc
EDIT: I wasn’t looking closely enough, it is indeed broken.
This is a problem on latest master ()
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: Upstream issue: The version of used in the (and possibly the one too?) standard library has a bug where it will sometimes walk off the end of the segment containing the section and segfault. I've struggled to reproduce this except in some proprietary code, but the backtrace looks like: There's a proposed fix in the linked LLVM issue, which can possibly be patched into libunwind before building the musl target if taking an updated libunwind isn't possible.
I ran into this as well.
There doesn't seem to be any movement on the LLVM issue since I raised it, not even an assignee. Do you know if this is normal behaviour for them? Or if I've mis-raised the issue?
Running into this as well at OneSignal
I can reproduce this on latest stable on an open source project: On the second run of the final command, the background process will segfault.
After much investigation, I think there's two bugs here, one that LLVM's unwinder will consider unreadable memory as part of the section, and one that the rust compiler creates invalid (unusual?) unwind information. The crash is specifically happening when trying to find unwind information for the frame above (not but the "c-runtime" main. Since the frames above the C entry point are provided by the runtime (musl in this case), they are contained in / which, in rust's musl-targeting stdlib have been provided. The provided object files have no unwind information in them: This in and of itself isn't a huge problem, the code stops trying to unwind when it can't find unwind information for the next frame (), so it should stop after which would be fine. so long as we can safely fail to find the unwind information. The issue is that libunwind's logic for searching for FDE (frame description entry) for the parent frame is pretty all-encompassing and runs in many phases, and one of these crashes (sometimes) if there searched for address is not present in the unwind information).
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: At a high level the process looks like () Look for a "compact unwinding table" Look for "DWARF unwind information" Look for ARM EHABI unwind info Look for dynamically created DWARF unwind entries For Rust x8664 musl binaries, the compiler has provided DWARF unwind information, so we fall into the second bullet (): No compact encoding hint, so the first section isn't interesting Search the section for an index for the frame - not present Check the local cache in case we've seen this frame before - we haven't Scan the whole of the section for the address of interest - CRASH! Digging further, we see that the logic for scanning the sector looks like (): Read a length field If it's 0 stop, we're done - rustc never seems to generate this "end-of-information" marker Skip over CIE entries For non-CIE entries work out if the address we're looking for is in the range of the entry, if so we've got our FDE Jump forward by the length of the CFI entry In each loop we check that the newly found CIE entry is in a reasonable place (between and ). If it's not, bail out for safety and fail the lookup. Unfortunately, as in the linked issue originally is incorrectly set too big (it's set to which is almost always wrong) so the unwind code will step right off the end of the segment and into one of: (LSDA) - This starts with a signature that is approximately , which is bigger than the error introduced by the miscalculation, so (after failing to parse the LSDA as a CFI entry) it jumps forward out of the range and bails out because the of the "reasonable location" check I mentioned above. The gap before (if the did not have a length that's a multiple of 32 and thus there's padding between the sections). In this case when it tries to read the next entry one of three things happens: The padding bytes happen to have a large value (when interpreted as a ) and we're in a similar position to the case where there's no padding, fail to parse the CFI entry, try to jump to the next one, realise we're jumping out of the allowed range and bail out for safety.
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: The padding bytes are medium sized when interpreted as a , in this case, after the failed parse, the unwinder jumps far enough to be off the end of the loaded segment, but not far enough to be past the so the sanity check passes and the unwinder attempts to read the next CFI entry, reads a 32-bit number from an invalid address and... :boom: The padding bytes are small when interpreted as a , and the unwinder jumps into a random part of the LSDA and we're back in a situation that's functionally similar to when we're reading the padding bytes and the same three options are still applicable in the next lookup. So, what's the bug(s) here? LLVM is miscalculating the section length (the original issue) Rustc (or the linker?) doesn't include the marker at the end of Either of these would fix this issue, probably both should be done?
Ah, there's another possible route for the crash: If the LOAD segement is really big, the signature at the start of the LSDA might not be big enough to jump past leading to an invalid read and a :boom:
I've ran into this issue as well. What's the status of this?
I've been looking at a proper fix for this and neither of the two paths I proposed above are yeilding simple results: LLVM miscalculating the section length: The simple fix I proposed in the upstream issue allows the unwinder to read arbitrary parts of the LOAD segment before bailing, which might have unexpected effects A more complex fix needs to calculate the section length at runtime, which is tricky as sections don't exist at runtime... Neither the nor section contains a length field so we're not simply told the length Maybe read the executable off disk (look in ) and parse the section table? Might not be readable to the current user. Might not even exist (not sure if this is possible, can you create a linux executable from an in-memory image?) Add terminator entry to the end of the section This relies on the static linker's behaviour, which is a shame as allows you to bring your own linker and both seem inconsistent about whether they add terminator entries, sometimes they do, sometimes they don't This feels like something that rustc can't fix locally or rely on externally Another option would be for LLVM to skip walking the section if the lookup in the fails.
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: It's unlikely to ever reveal anything new, and it seems that this section is just un-walkable with any kind of reliability.
Here are two tested workarounds, neither very pretty, but both work: to your Cargo config a build, extract the link script from the linker verbose output the lines: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) } them to: .ehframe : ONLYIFRO { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ... .ehframe : ONLYIFRW { KEEP ((.ehframe)) (.ehframe.) LONG(0x0) } ( is the CIE terminator) off this script somewhere in Cargo config (probably under the Musl target) an object containing just the terminator: 2, Add to your Cargo config (probably under the Musl target)
Hi! Is this still an issue? If so, is there perhaps a simpler way to reproduce this than the instructions linked above?
The setup that's needed is: A large LOAD segment (the one containing and ) Specifically the section needs to be deep into the segment How deep it has to be is roughly determined by the first of the section So something like the following should trigger the fault: This builds a huge section, which lives before the section so should lead to the crash. Hedging words because I can't reproduce the issue on my development machine (I run out of RAM and get OOM-killered).
Hmm, that doesn't seem to be sufficient (tested on the current stable and nightly). I get this output when building and running this on Arch Linux: I also get the same output when using to capture the backtrace.
I noticed the wrong ehSectionEnd calculation independently and filed
It looks like the gcc driver on Alpine adds the file to the link, which includes a terminator in . It seems that the rustc driver doesn't add something like this? (LLVM has a that has an .ehframe terminator, so maybe that's relevant to rustc.)
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: FWIW, it looks like LLVM's LLD linker automatically adds a terminator to the end of .ehframe, even if one isn't present in the linker inputs, so that could be a workaround: I think libunwind should stop scanning .ehframe when it finds unwind info from .ehframehdr (i.e. the GNUEH_FRAME segment).
Rustc's musl-targeting link includes: I don't exactly know where the files come from (they're shipped with the compiler toolchain, e.g. mine are in ) but looking at the musl codebase, there's no terminator in : (Intriguingly there's also no in the musl codebase, suggesting Rustc gets these objects from somewhere else?)_ I wouldn't expect to see a or since the rustc musl target doesn't include a C++ runtime and musl libc doesn't define either of these objects for the C runtime either.
It looks like musl's crt1 is a C file, not assembly. crt/{S,r,}crt1.c When crtbegin and crtend were to LLVM (), there was some discussion about which project is responsible for which aspects of the CRT begin/end files. Apparently the status quo on Linux is that: the compiler (e.g. libgcc) provides crtbegin/crtend the libc provides crti/crte (and maybe crt1, too?) That is the case on my gLinux (i.e. Debian) system: /usr/lib/x8664-linux-gnu/crt[1ie].o all come from the libc6-dev:amd64 package /usr/lib/gcc/x8664-linux-gnu/9/{crtbegin.o,crtend.o} come from libgcc-9-dev:amd64 The .ehframe terminator is usually in crtend, which is part of libgcc (not glibc or musl). LLVM's compiler-rt also provides crtbegin/crtend files. The gcc and clang drivers link a crtend object even for C programs. On Alpine, the gcc driver links a libgcc crtend object. It looks like rustc typically invokes the driver, but when it's targeting musl, it enters a mode where it provides the start files explicitly, and in this mode, it doesn't include crtbegin/crtend. For Alpine, I see , , , and .
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: For rustc/glibc, I don't see any of those flags, so the cc driver uses the default CRT begin/end/i/n/1 files. I see that rustc documents a lot of this at The unwinder needs the .ehframe terminator, because the .ehframehdr search table is optional, and because .ehframehdr has the start address of .ehframe, but not its size. ( / ). I don't think it's reasonable to open the ELF file indicated by dlpiname -- in principle, that duplicates the work done by the loader, and I can think of many specific things that wouldn't work. (e.g. the vdso, the executable w/glibc, Android's androiddlopen_ext and ability to map DSOs from zip files, unlinked files, etc).
Using self-contained mode is not generally recommended for serious work. If the compiler heuristics enable it by default, then it can be explicitly disabled with , then gcc will be used for linking without and will find all the necessary CRT objects by itself. Then it's important to make sure that gcc for the right target (musl in this case) is used by rustc.
If the compiler heuristics enable it by default Here's a FIXME for improving the heuristic for musl targets:
Thanks for that, very interesting. I think there are two separate use cases for musl-targeting builds: an environment where there's a full "native musl" toolchain (like on Alpine etc) where I think you're correct that we shouldn't use and should let the toolchain sort it out for us though I can't see an easy way to tell if a real toolchain is available a generic linux environment where the goal is fully static binaries (for easy of redistribution/embedding in thin container images/etc.)
Code change:
DependencyType::TargetSelfContained, ); } <ins> let crt_path = builder.ensure(native::CrtBeginEnd { target }); </ins> for &obj in &["crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"] { <del> let src = compiler_file(builder, builder.cc(target), target, obj); </del> <ins> let src = crt_path.join(obj); </ins> let target = libdir_self_contained.join(obj); builder.copy(&src, &target); target_deps.push((target, DependencyType::TargetSelfContained));

Related discussion:
text: where there's likely not a native toolchain and rustc is forced to work out the answers for itself (as an aside no longer works as the "linker" for musl targets, since it doesn't support which is enabled in rustc as of the last release) I'm worrying about the latter case and I think from above the fix for that is: to add the terminator in builds as well as ones and include it in the target package alongside the (so rustup etc fetch it) the link command rustc emits for the musl target to include before Some side questions: Does the above sound sensible to people? Do we need to include any of too? (I think not, but I'm no expert :shrug:) Do other targets need similar treatment? musl?
In the latter case it would make sense to me for rustc to invoke an actual linker (///etc) since at the moment it goes via a compiler but has to tell the compiler to not do anything and just to pass the link args to the linker anyway. This is off topic for this discussion though.
If we need to improve the self-contained mode specifically, then I think we can just ship the begin/end objects and link to them like gcc does obsoleting the comment cited in That appears to be the simplest solution. If that doesn't work out (e.g. due to licensing), then the necessary parts can be to and linked as , as you suggested above.
Which / objects were you thinking? 's? LLVM's? If you're right and it's the compiler that ships the begin/end then maybe it's right for to have it's own (though given that the link might contain code compiled by random compilers (from scripts) as well as compiled by , which is "the compiler" for the sake of this discussion)?
's? LLVM's? I don't know, but looks like they should be compatible. At least on Ubuntu both gcc and clang link to gcc's objects. The gcc ones can be just copied by rustbuild if the license allows, the LLVM ones can be used if we need to build them by ourselves (they are a part of compiler-rt).
adds crtbegin/crtend objects to Rust distribution and links to them in self-contained mode as was suggested in , so it should fix this issue.
I still have this problem with clang's compiler-rt:
Code change:
cx.generated_synthetics.insert((ty, trait_def_id)); <ins> let hir_imp = impl_def_id.as_local() .map(|local| cx.tcx.hir().expect_item(local)) .and_then(|item| if let hir::ItemKind::Impl(i) = &item.kind { Some(i) } else { None }); let items = match hir_imp { Some(imp) => imp .items .iter() .map(|ii| cx.tcx.hir().impl_item(ii.id).clean(cx)) .collect::<Vec<_>>(), None => cx.tcx .associated_items(impl_def_id) .in_definition_order() .map(|x| x.clean(cx)) .collect::<Vec<_>>(), }; </ins> impls.push(Item { name: None, attrs: Default::default(),

Related discussion:
text: Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):
Code change:
<ins> error: expected one of `(`, `,`, `=`, `{`, or `}`, found `#` --> $DIR/help-set-edition-ice-122130.rs:2:6 | LL |     s#[c"owned_box"] |      ^ expected one of `(`, `,`, `=`, `{`, or `}` | = note: you may be trying to write a c-string literal = note: c-string literals require Rust 2021 or later = help: pass `--edition 2021` to `rustc` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error: expected item, found `"owned_box"` --> $DIR/help-set-edition-ice-122130.rs:2:9 | LL |     s#[c"owned_box"] |         ^^^^^^^^^^^ expected item | = note: for a full list of items that can appear in modules, see <https://doc.rust-lang.org/reference/items.html> error: aborting due to 2 previous errors </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '', 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '' 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: --
Slightly smaller:
cc
Somehow this subdiag enum being to a diagnostic causes but the looks okay to me...?
Also suspicious:
Seems like for the subdiag whose fluent messages contain a variable, they need to be eagerly translated via instead of using . However I'm not very familiar with this distinction.
Code change:
<ins> // Suggest to a user to use the print macros // instead to use the printf. fn main() { let x = 4; printf("%d", x); //~^ ERROR cannot find function `printf` in this scope //~| HELP you may have meant to use the `print` macro } </ins>

Related discussion:
text: We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor
Code change:
#[subdiagnostic] pub req_introduces_loc: Option<ReqIntroducedLocations>, <ins> pub has_param_name: bool, pub param_name: String, </ins> pub spans_empty: bool, pub has_lifetime: bool, pub lifetime: String,

Related discussion:
text: [ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :