jiebi/CodeConvo huggingface dataset:
Code change:
<ins> # only-linux # ignore-32bit -include ../tools.mk all: $(RUSTC) eh_frame-terminator.rs $(call RUN,eh_frame-terminator) | $(CGREP) '1122334455667788' objdump --dwarf=frames $(TMPDIR)/eh_frame-terminator | $(CGREP) 'ZERO terminator' </ins>

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:
<ins> # only-linux # ignore-32bit -include ../tools.mk all: $(RUSTC) eh_frame-terminator.rs $(call RUN,eh_frame-terminator) | $(CGREP) '1122334455667788' objdump --dwarf=frames $(TMPDIR)/eh_frame-terminator | $(CGREP) 'ZERO terminator' </ins>

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:
<ins> # only-linux # ignore-32bit -include ../tools.mk all: $(RUSTC) eh_frame-terminator.rs $(call RUN,eh_frame-terminator) | $(CGREP) '1122334455667788' objdump --dwarf=frames $(TMPDIR)/eh_frame-terminator | $(CGREP) 'ZERO terminator' </ins>

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:
<ins> # only-linux # ignore-32bit -include ../tools.mk all: $(RUSTC) eh_frame-terminator.rs $(call RUN,eh_frame-terminator) | $(CGREP) '1122334455667788' objdump --dwarf=frames $(TMPDIR)/eh_frame-terminator | $(CGREP) 'ZERO terminator' </ins>

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:
<ins> // check-fail // dont-check-compiler-stdout // dont-check-compiler-stderr fn�a<e>(){fn�p(){e}} //~ ERROR unknown start of token: u{fffd} //~^ ERROR unknown start of token: u{fffd} //~^^ ERROR can't use generic parameters from outer function [E0401] //~^^^ WARN type parameter `e` should have an upper camel case name fn main(){} </ins>

Related discussion:
text: I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "unknown start of token", so low priority. I guess that one part of the code treats as whitespace, while another part of the code treats it as not whitespace, causing a logic error with this input. Affected versions: nightly 2022-02-26 and beta 1.60.0-beta1 are affected, but stable 1.59.0 does not ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed by , different enough to the test that I'll mark as needs-test. But anybody feel free to close this if we don't generally add fuzzed inputs to tests
Code change:
<ins> error[E0308]: mismatched types --> $DIR/suggest-call-on-pat-mismatch.rs:7:12 | LL |     if let E::One(var1, var2) = var { |            ^^^^^^^^^^^^^^^^^^   --- this expression has type `fn(i32, i32) -> E {E::One}` |            | |            expected enum constructor, found `E` | = note: expected enum constructor `fn(i32, i32) -> E {E::One}` found enum `E` help: use parentheses to construct this tuple variant | LL |     if let E::One(var1, var2) = var(/* i32 */, /* i32 */) { |                                    ++++++++++++++++++++++ error[E0308]: mismatched types --> $DIR/suggest-call-on-pat-mismatch.rs:13:9 | LL |     let Some(x) = Some; |         ^^^^^^^   ---- this expression has type `fn(_) -> Option<_> {Option::<_>::Some}` |         | |         expected enum constructor, found `Option<_>` | = note: expected enum constructor `fn(_) -> Option<_> {Option::<_>::Some}` found enum `Option<_>` help: use parentheses to construct this tuple variant | LL |     let Some(x) = Some(/* value */); |                       +++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </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. 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 suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- 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 --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix
Code change:
/// /// [`to_ascii_uppercase()`]: #method.to_ascii_uppercase #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_uppercase(&mut self) { *self = self.to_ascii_uppercase(); }

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Code change:
> { after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: NonNull<[T]>, tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, <ins> _phantom: PhantomData<&'a T>, </ins> } impl<'a, T, A: Allocator> Drain<'a, T, A> { pub(super) unsafe fn new( after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: &'a [MaybeUninit<T>], tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, ) -> Self { <del> Drain { after_tail, after_head, iter, deque } </del> <ins> let ring = unsafe { NonNull::new_unchecked(ring as *const [MaybeUninit<T>] as *mut _) }; Drain { after_tail, after_head, ring, tail, head, deque, _phantom: PhantomData } </ins> } }

Related discussion:
text: liballoc's fails when run in Miri. The error occurs in the call: is called with a as argument. contains contains a shared reference to a slice; that slice is thus marked as "must not be mutated for the entire duration of this function call". calls calls calls calls , which eventually drops the . calls to re-arrange stuff (I have not fully understood this yet), and in some cases this will end up writing to memory that the slice in points to. I am not sure what the best way to fix this is. We have to fix holding (indirectly) a shared reference to something that it'll mutate during its . The mutation is likely there for a reason, so I guess the shared reference has to go. (FWIW, this shared reference already caused other trouble, but that was fixed by ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah I guess just change it to and toss in a PhantomData for the borrow. shrug
You mean, change this in as well? Sure, that should work. In principle this reduces the precision of compiler analyses on .
ahh misread. maybe would just not use Iter then. depends on what the impl looks like now
But the first thing it does is which should exhaust the such that its is an empty slice. I suppose its pointer will still be somewhere in the deque's memory, but with length 0 it can't actually read anything. Is that not good enough to appease Miri?
No. This code still matches the pattern There is no notion of "exhausting" or "consuming" a shared reference. When you create a shared reference with a certain lifetime, you promise that until that lifetime ends, no mutation happens. here is mutable so you can change what the slice points to, but that has no effect at all on the guarantees that have been made about the value that was initially passed to . Now, lifetimes are an entirely static concept, so for Stacked Borrows a "lifetime" generally is "until the pointer is used for the last time".
Code change:
> { after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: NonNull<[T]>, tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, <ins> _phantom: PhantomData<&'a T>, </ins> } impl<'a, T, A: Allocator> Drain<'a, T, A> { pub(super) unsafe fn new( after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: &'a [MaybeUninit<T>], tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, ) -> Self { <del> Drain { after_tail, after_head, iter, deque } </del> <ins> let ring = unsafe { NonNull::new_unchecked(ring as *const [MaybeUninit<T>] as *mut _) }; Drain { after_tail, after_head, ring, tail, head, deque, _phantom: PhantomData } </ins> } }

Related discussion:
text: However, for the special case of a reference being passed to a function, Stacked Borrows asserts that the "lifetime" will last at least as long as the function the reference is pointed to. (This is enforced by the "barriers" explained .) This is extremely useful for optimizations.
forward to . I wouldn't want to copy those.
Oh, I also didn't realize that doesn't actually shrink down to an empty slice -- it only updates its indexes. It would otherwise have to use two slices for the wrapped head and tail. So that full shared reference does still exist after the iterator is exhausted. (This also raises the validity question of having references to uninitialized data.) Could we base on instead? We could arrange to work through that mutable reference too, so there's no question of mutable aliasing.
That might work. However, must not access in that case -- that would be in conflict with the unique reference in .
Hmm, does need to be covariant over ? I guess would break that.
Actually this idea of "consuming a shared ref" is far from unique to ... the following code also errors in Miri:
As I understand it, Miri and stacked borrows should be "more powerful" than the Rust borrow checker, right? So, is this an example where Miri does not match what Rust allows or is this a bug in Rust that could lead to undefined behaviour in safe code? ()
-- I believe is admitting that example as something that should be allowed. But this issue with involves raw pointers, which rustc doesn't check at all, so miri is in uncharted waters here.
This is up for us all to decide. I can't tell you. ;) Not necessary. I have argued that / are problematic long before Stacked Borrows. The lifetimes there are, strictly speaking, wrong. I think it would be reasonable to rule that they have to use raw pointers.
FWIW here is a stand-alone version of the testcase to reproduce this with Miri (but it needs access to some private internals):
See for the issue about whether Stacked Borrows should allow such code or not. For now, with , Miri accepts this code again. So I am going to close the issue here. It still represents an interesting data point to inform what Stacked Borrows rules should be.
Code change:
> { after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: NonNull<[T]>, tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, <ins> _phantom: PhantomData<&'a T>, </ins> } impl<'a, T, A: Allocator> Drain<'a, T, A> { pub(super) unsafe fn new( after_tail: usize, after_head: usize, <del> iter: Iter<'a, T>, </del> <ins> ring: &'a [MaybeUninit<T>], tail: usize, head: usize, </ins> deque: NonNull<VecDeque<T, A>>, ) -> Self { <del> Drain { after_tail, after_head, iter, deque } </del> <ins> let ring = unsafe { NonNull::new_unchecked(ring as *const [MaybeUninit<T>] as *mut _) }; Drain { after_tail, after_head, ring, tail, head, deque, _phantom: PhantomData } </ins> } }

Related discussion:
text: nods wisely just gotta stand still long enough for the spec to bend around you
;-) I don't think the decision is made either way, but for now with several counterexamples in libstd, it is not helpful for Miri to complain about this. Plus, this matches what we formalized in Coq; the basic optimizations that we considered so far are all fine with this change.
See there actually is a bug here right now, because we do emit for passed to a function. So what Miri found is actually UB in the LLVM IR that we are generating right now. Reopening for now, but maybe it makes more sense to treat this as a duplicate of
Smaller reproduction that I found in (a now closed dupe of this issue) that doesn't rely on VecDeque internals, that fails now with
re-enables the part of Stacked Borrows that got disabled (in parts) to work around the issue, before I knew that we actually have here and are risking real miscompilations.
claim
Code change:
use crate::io::ErrorKind; use crate::str; <del> // FIXME(#10380) these tests should not all be ignored on android. </del> <ins> #[cfg(target_os = "android")] fn shell_cmd() -> Command { Command::new("/system/bin/sh") } #[cfg(not(target_os = "android"))] fn shell_cmd() -> Command { Command::new("/bin/sh") } </ins> #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn smoke() { let p = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 0"]).spawn() } else { <del> Command::new("true").spawn() </del> <ins> shell_cmd().arg("-c").arg("true").spawn() </ins> }; assert!(p.is_ok()); let mut p = p.unwrap();

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.