jiebi/CodeConvo huggingface dataset:
Code change:
tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

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:
tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

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:
tool::Rustfmt, tool::Miri, tool::CargoMiri, <del> native::Lld </del> <ins> native::Lld, native::CrtBeginEnd </ins> ), Kind::Check | Kind::Clippy { .. } | Kind::Fix | Kind::Format => describe!( check::Std,

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:
#[derive(Copy, Clone, RustcEncodable, RustcDecodable)] enum EntryKind { <ins> AnonConst(mir::ConstQualifs, Lazy<RenderedConst>), </ins> Const(mir::ConstQualifs, Lazy<RenderedConst>), ImmStatic, MutStatic,

Related discussion:
text: Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :
Code change:
}; // rhs has holes ( `$id` and `$(...)` that need filled) let tts = transcribe(&cx.parse_sess.span_diagnostic, Some(named_matches), rhs); <ins> if cx.trace_macros() { trace_macros_note(cx, sp, format!("to `{}`", tts)); } </ins> let directory = Directory { path: cx.current_expansion.module.directory.clone(), ownership: cx.current_expansion.directory_ownership,

Related discussion:
text: Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.
Code change:
}); cx.emit_spanned_lint(DEREF_INTO_DYN_SUPERTRAIT, cx.tcx.def_span(item.owner_id.def_id), SupertraitAsDerefTarget { t, <del> target_principal: target_principal.to_string(), </del> <ins> target_principal, </ins> label, }); }

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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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 label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve
Code change:
return; }; let coroutine_ty = body.local_decls[ty::CAPTURE_STRUCT_LOCAL].ty; <del> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!() }; </del> <ins> if coroutine_ty.references_error() { return; } let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("{body:#?}") }; </ins> let coroutine_kind = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap(); if coroutine_kind == ty::ClosureKind::FnOnce {

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )
Code change:
return; }; let coroutine_ty = body.local_decls[ty::CAPTURE_STRUCT_LOCAL].ty; <del> let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!() }; </del> <ins> if coroutine_ty.references_error() { return; } let ty::Coroutine(_, args) = *coroutine_ty.kind() else { bug!("{body:#?}") }; </ins> let coroutine_kind = args.as_coroutine().kind_ty().to_opt_closure_kind().unwrap(); if coroutine_kind == ty::ClosureKind::FnOnce {

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Code change:
}; if let ObligationCauseCode::ImplDerivedObligation(obligation) = &*code { <del> let expected_trait_ref = obligation.parent_trait_ref.skip_binder(); let new_imm_trait_ref = ty::TraitRef::new(obligation.parent_trait_ref.def_id(), imm_substs); let new_mut_trait_ref = ty::TraitRef::new(obligation.parent_trait_ref.def_id(), mut_substs); </del> <ins> let expected_trait_ref = obligation.parent_trait_ref; let new_imm_trait_ref = poly_trait_ref .rebind(ty::TraitRef::new(obligation.parent_trait_ref.def_id(), imm_substs)); let new_mut_trait_ref = poly_trait_ref .rebind(ty::TraitRef::new(obligation.parent_trait_ref.def_id(), mut_substs)); </ins> return try_borrowing(new_imm_trait_ref, new_mut_trait_ref, expected_trait_ref, &[]); } else if let ObligationCauseCode::BindingObligation(_, _) | ObligationCauseCode::ItemObligation(_) = &*code { return try_borrowing( <del> ty::TraitRef::new(trait_ref.def_id, imm_substs), ty::TraitRef::new(trait_ref.def_id, mut_substs), trait_ref, </del> <ins> poly_trait_ref.rebind(ty::TraitRef::new(trait_ref.def_id, imm_substs)), poly_trait_ref.rebind(ty::TraitRef::new(trait_ref.def_id, mut_substs)), *poly_trait_ref, </ins> &never_suggest_borrow[..], ); } else {

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. --When creating this I found that it did not error if the function was not called and it also seemed to require it to be a function not just an argument of type T or (from what I tested) a different impl Trait although it could be any Fn* trait <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This appears to only happen on nightly while stable and beta generate useful error reports <!-- 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 --
label regression-from-stable-to-nightly
does not ICE but errors correctly while does ICE
glacier ""
searched nightlies: from nightly-2021-09-17 to nightly-2021-09-18 regressed nightly: nightly-2021-09-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsThat's , so cc
I've got this. claim Interestingly, this is precisely the kind of thing that is hopefully going to help harden against: "hidden" s when calling and such
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
error: invalid register `invalid`: unknown register <del> --> $DIR/issue-72570.rs:7:18 </del> <ins> --> $DIR/issue-72570.rs:9:18 </ins> | LL |         asm!("", in("invalid") "".len()); |                  ^^^^^^^^^^^^^^^^^^^^^^

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. --code from ./src/test/ui/asm/issue- <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Does this still happen with (now merged)
I can confirm its fixed. We can probably close this issue.
Closing this, thanks for taking a look!
Code change:
<ins> error[E0004]: non-exhaustive patterns: `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered --> $DIR/issue-72377.rs:8:11 | LL |     match (x, y) { |           ^^^^^^ patterns `(A, Some(A))`, `(A, Some(B))`, `(B, Some(B))` and 2 more not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `(X, Option<X>)` error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>

Related discussion:
text: A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true
Code change:
#[test] #[cfg(unix)] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn signal_reported_right() { use crate::os::unix::process::ExitStatusExt; <del> let mut p = Command::new("/bin/sh").arg("-c").arg("read a").stdin(Stdio::piped()).spawn().unwrap(); </del> <ins> let mut p = shell_cmd().arg("-c").arg("read a").stdin(Stdio::piped()).spawn().unwrap(); </ins> p.kill().unwrap(); match p.wait().unwrap().signal() { Some(9) => {}

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
<ins> // check-pass // https://github.com/rust-lang/rust/issues/113257 #![deny(trivial_casts)] // The casts here are not trivial. struct Foo<'a> { a: &'a () } fn extend_lifetime_very_very_safely<'a>(v: *const Foo<'a>) -> *const Foo<'static> { // This should pass because raw pointer casts can do anything they want. v as *const Foo<'static> } trait Trait {} fn assert_static<'a>(ptr: *mut (dyn Trait + 'a)) -> *mut (dyn Trait + 'static) { ptr as _ } fn main() { let unit = (); let foo = Foo { a: &unit }; let _long: *const Foo<'static> = extend_lifetime_very_very_safely(&foo); } </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. --I tried this code: . I expected to see this happen: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.
Code change:
// If this is a floating point literal that ends with '.', // get rid of it to stop this from becoming a member access. let snippet = snippet.strip_suffix('.').unwrap_or(&snippet); err.span_suggestion( lit.span, &format!(

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
use rustc_metadata::creader::{CStore, LoadedMacro}; use rustc_middle::ty::fast_reject::SimplifiedType; use rustc_middle::ty::{self, TyCtxt}; <ins> use rustc_span::def_id::LOCAL_CRATE; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Symbol};

Related discussion:
text: for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you