jiebi/CodeConvo huggingface dataset:
Code change:
// the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

Related discussion:
text: nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)
Code change:
// the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

Related discussion:
text: cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.
Code change:
// the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

Related discussion:
text: It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.
Code change:
// the address of the symbol to ensure it sticks around. #[link_section = ".CRT$XLB"] <del> #[linkage = "external"] </del> #[allow(dead_code, unused_variables)] <ins> #[used] // we don't want LLVM eliminating this symbol for any reason, and // when the symbol makes it to the linker the linker will take over </ins> pub static p_thread_callback: unsafe extern "system" fn(c::LPVOID, c::DWORD, c::LPVOID) = on_tls_callback;

Related discussion:
text: I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!
Code change:
retry aws s3 cp --no-progress --recursive --acl public-read ./$upload_dir s3://$DEPLOY_BUCKET/$deploy_dir/$BUILD_SOURCEVERSION env: AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) <del> condition: and(succeeded(), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) </ins> displayName: Upload artifacts # Upload CPU usage statistics that we've been gathering this whole time. Always

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
extern_return_twou64s(); foreign_fn_with_byval(); issue_28676(); <ins> issue_62350(); </ins> struct_return(); }

Related discussion:
text: We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).
Code change:
extern_return_twou64s(); foreign_fn_with_byval(); issue_28676(); <ins> issue_62350(); </ins> struct_return(); }

Related discussion:
text: Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway
Code change:
-include ../../run-make-fulldeps/tools.mk <del> all: $(TMPDIR)/$(call BIN,directly_linked) $(TMPDIR)/$(call BIN,indirectly_linked) $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </del> <ins> all: $(TMPDIR)/$(call BIN,directly_linked)  $(TMPDIR)/$(call BIN,directly_linked_test_plus_whole_archive)  $(TMPDIR)/$(call BIN,directly_linked_test_minus_whole_archive)  $(TMPDIR)/$(call BIN,indirectly_linked)  $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </ins> $(call RUN,directly_linked) | $(CGREP) 'static-initializer.directly_linked.' <ins> $(call RUN,directly_linked_test_plus_whole_archive) --nocapture | $(CGREP) 'static-initializer.' $(call RUN,directly_linked_test_minus_whole_archive) --nocapture | $(CGREP) -v 'static-initializer.' </ins> $(call RUN,indirectly_linked) | $(CGREP) 'static-initializer.indirectly_linked.' $(call RUN,indirectly_linked_via_attr) | $(CGREP) 'static-initializer.native_lib_in_src.'

Related discussion:
text: I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).
Code change:
Scope::Binder { where_bound_origin: Some(hir::PredicateOrigin::ImplTrait), .. } => { <del> let mut err = self.tcx.sess.struct_span_err( lifetime_ref.ident.span, "`impl Trait` can only mention lifetimes bound at the fn or impl level", ); err.span_note(self.tcx.def_span(region_def_id), "lifetime declared here"); err.emit(); </del> <ins> self.tcx.sess.emit_err(errors::LateBoundInApit::Lifetime { span: lifetime_ref.ident.span, param_span: self.tcx.def_span(region_def_id), }); </ins> return; } Scope::Root { .. } => break,

Related discussion:
text: <!-- 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
minimized
Bisected to :sweatsmile:
Code change:
use libc::types::os::arch::c95::{c_int, size_t}; pub static SIGTRAP : c_int = 5; <ins> pub static SIGPIPE: c_int = 13; pub static SIG_IGN: size_t = 1; </ins> pub static GLOB_APPEND   : c_int = 0x0001; pub static GLOB_DOOFFS   : c_int = 0x0002;

Related discussion:
text: Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from
Code change:
eprint('ERROR: vendoring required, but vendor directory does not exist.') eprint('       Run `cargo vendor {}` to initialize the ' 'vendor directory.'.format(sync_dirs)) <del> eprint('Alternatively, use the pre-vendored `rustc-src` dist component.') </del> <ins> eprint('       Alternatively, use the pre-vendored `rustc-src` dist component.') eprint('       To get a stable/beta/nightly version, download it from: ') eprint('       ' 'https://forge.rust-lang.org/infra/other-installation-methods.html#source-code') eprint('       To get a specific commit version, download it using the below URL,') eprint('       replacing <commit> with a specific commit checksum: ') eprint('       ' 'https://ci-artifacts.rust-lang.org/rustc-builds/<commit>/rustc-nightly-src.tar.xz') eprint('       Once you have the source downloaded, place the vendor directory') eprint('       from the archive in the root of the rust project.') </ins> raise Exception("{} not found".format(vendor_dir)) if not os.path.exists(cargo_dir):

Related discussion:
text: While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim
Code change:
<ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>

Related discussion:
text: <!-- 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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.
Code change:
<ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>

Related discussion:
text: To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
More minimal (no_core) Is correct in html ! and wrong in json