jiebi/CodeConvo huggingface dataset:
Code change:
<ins> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } fn bad<T>(f: fn(&'static str) -> T) { test(Compose(f, |_| {})); //~ ERROR: mismatched types } fn main() {} </ins>

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
/// A type that allows convenient usage of a UDP stream connected to one /// address via the `Reader` and `Writer` traits. <ins> /// /// # Note /// /// This structure has been deprecated because `Reader` is a stream-oriented API but UDP /// is a packet-oriented protocol. Every `Reader` method will read a whole packet and /// throw all superfluous bytes away so that they are no longer available for further /// method calls. #[deprecated] </ins> pub struct UdpStream { socket: UdpSocket, connected_to: SocketAddr

Related discussion:
text: change this to something more appropriate. This was introduced in commit when still returned . This should either block until a message from the correct sender arrives or return an error.
Code change:
continue; } <ins> // HACK: `async fn() -> Self` in traits is "ok"... // This is not really that great, but it's similar to why the `-> Self` // return type is well-formed in traits even when `Self` isn't sized. if let ty::Param(param_ty) = *proj_term.kind() && param_ty.name == kw::SelfUpper && matches!(opaque.origin, hir::OpaqueTyOrigin::AsyncFn(_)) && opaque.in_trait { continue; } </ins> let proj_ty = Ty::new_projection(cx.tcx, proj.projection_ty.def_id, proj.projection_ty.args); // For every instance of the projection type in the bounds,

Related discussion:
text: When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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 is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with
Code change:
// panicking thread consumes at least 2 bytes of address space. static GLOBAL_PANIC_COUNT: AtomicUsize = AtomicUsize::new(0); <ins> // Return the state of the ALWAYS_ABORT_FLAG and number of panics. // // If ALWAYS_ABORT_FLAG is not set, the number is determined on a per-thread // base (stored in LOCAL_PANIC_COUNT), i.e. it is the amount of recursive calls // of the calling thread. // If ALWAYS_ABORT_FLAG is set, the number equals the *global* number of panic // calls. See above why LOCAL_PANIC_COUNT is not used. </ins> pub fn increase() -> (bool, usize) { <del> ( GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed) & ALWAYS_ABORT_FLAG != 0, </del> <ins> let global_count = GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed); let must_abort = global_count & ALWAYS_ABORT_FLAG != 0; let panics = if must_abort { global_count & !ALWAYS_ABORT_FLAG } else { </ins> LOCAL_PANIC_COUNT.with(|c| { let next = c.get() + 1; c.set(next); next <del> }), ) </del> <ins> }) }; (must_abort, panics) </ins> } pub fn decrease() {

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 am trying to fix it so that Rust's stdlib prevents unwinding, or allocating, in the child, after a fork on Unix (including in ). That is . (Allocation after fork of a multithreaded program is UB in several libcs.) I a new test case, Unfortunately this test fails, but just on Android: I have few good theories as to why. I wrote some speculations: I think this probably needs attention from an Android expert to try to repro and fix this issue. I suspect it's a problem with the library rather than the tests. The worst case is that it might be a general UB bug in Android Rust programs using or . I'm filing this issue here to try to ask for help again, since writing in doesn't seem like a particularly good way of getting the attention of Android folks. If we can't get a resolution, reluctantly, I guess I will disable that test on Android so that my MR can go through. The current situation is quite a hazard (see eg "panic! in Command child forked from non-main thread results in exit status 0") I will try to explain what the test does and what the symptoms seem to mean: The test file has a custom global allocator, whose purpose is to spot allocations in the child after fork. That global allocator has an atomic variable which is supposed to contain either zero (initially, meaning it's not engaged yet) or the process's pid. Whenever an allocator method is called, we read the atomic and, if it is not zero, we check it against . If it doesn't match we <strike</strike. The test enters , and engages the stunt allocator, recording the program's pid. Each call to (which is called from and therefore from ) produces output from . We see only one of these, so this must be the first test, . The test uses to fork. In the child, it calls (my new function to disable panic unwinding). It then panics (using the provided closure). This ought to result in the program dying with (or maybe or ). The parent collects the child's exit status. For the first test case, we run .
Code change:
// panicking thread consumes at least 2 bytes of address space. static GLOBAL_PANIC_COUNT: AtomicUsize = AtomicUsize::new(0); <ins> // Return the state of the ALWAYS_ABORT_FLAG and number of panics. // // If ALWAYS_ABORT_FLAG is not set, the number is determined on a per-thread // base (stored in LOCAL_PANIC_COUNT), i.e. it is the amount of recursive calls // of the calling thread. // If ALWAYS_ABORT_FLAG is set, the number equals the *global* number of panic // calls. See above why LOCAL_PANIC_COUNT is not used. </ins> pub fn increase() -> (bool, usize) { <del> ( GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed) & ALWAYS_ABORT_FLAG != 0, </del> <ins> let global_count = GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed); let must_abort = global_count & ALWAYS_ABORT_FLAG != 0; let panics = if must_abort { global_count & !ALWAYS_ABORT_FLAG } else { </ins> LOCAL_PANIC_COUNT.with(|c| { let next = c.get() + 1; c.set(next); next <del> }), ) </del> <ins> }) }; (must_abort, panics) </ins> } pub fn decrease() {

Related discussion:
text: This extracts the signal number from it and checks that it is as expected. On other systems this works. In the failing test, this test fails. The assertion on fails. Meaning, the child did die of a signal but the signal number wasn't the one expected. The previous debug print shows that the raw wait status (confusingly described by Rust stdlib as an "exit status") is <strike</strike. Usually, a bare number like that in a wait status is a signal number, and indeed that seems to be the case here since is . On Linux (and most Unices), is and 10 is . Ie, it seems that the child tried to allocate memory, despite my efforts to make sure that panicking does not involve allocation. Weirdly, a more-portable test case which uses and does not insist on specific signal numbers passes. It's definitely my stunt allocator which is tripping here, because when I changed it to use instead of , the failing test case signal number changed too.
modify labels +O-android +T-libs-impl
<strike provided an explanation here I still think there is a bug here but it is not Android-specific. I have a WIP branch to try to address it, so I think it's probably best if I close this issue and submit that as an MR when it's ready.</strike
My first guesses were right. In where I changed the stunt allocator to use , we see this:
I found a memory allocation with a patched Miri: With this code:
Apparently, the thread locals aren't working as expected. I think the child after fork is being treated as a new thread, and then the thread local storage has to be re-created. I think the surviving thread in the fork should inherit all the thread-locals from the forking thread in the parent.
But I just tested the code after , so there's no "new thread" or "parent" here...
Oh! Yes. You are right. Evidently the first use of this thread-local allocates. Presumably that would happen on a new thread as well as on the initial thread. Having panic rely on thread-locals, and thread-locals rely on the allocator, seems unfortunate. Having panic allocate is not good, especially when actually it's just trying to abort precisely to avoid this.
Code change:
// panicking thread consumes at least 2 bytes of address space. static GLOBAL_PANIC_COUNT: AtomicUsize = AtomicUsize::new(0); <ins> // Return the state of the ALWAYS_ABORT_FLAG and number of panics. // // If ALWAYS_ABORT_FLAG is not set, the number is determined on a per-thread // base (stored in LOCAL_PANIC_COUNT), i.e. it is the amount of recursive calls // of the calling thread. // If ALWAYS_ABORT_FLAG is set, the number equals the *global* number of panic // calls. See above why LOCAL_PANIC_COUNT is not used. </ins> pub fn increase() -> (bool, usize) { <del> ( GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed) & ALWAYS_ABORT_FLAG != 0, </del> <ins> let global_count = GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed); let must_abort = global_count & ALWAYS_ABORT_FLAG != 0; let panics = if must_abort { global_count & !ALWAYS_ABORT_FLAG } else { </ins> LOCAL_PANIC_COUNT.with(|c| { let next = c.get() + 1; c.set(next); next <del> }), ) </del> <ins> }) }; (must_abort, panics) </ins> } pub fn decrease() {

Related discussion:
text: Instead of having UB, I think it would be fine to only check the number of overall current panics calls (as stored in ignoring ). If it is higher than 2, assume we have a recursion (results in false positives in case two or more threads panic at the same time). ==In case we have two panics going on in parallel by two threads there is the chance that we don't output , but it prevents UB. Also, when one thread calls it will often happen that the second thread will be killed soon and outputs nothing at all. In other cases (only one thread panics), there should be no difference. A change could look like that (high probability I've missed something!): This change passes all tests of for targets and QNX on AArch64.
Would you please try to test the fix above to check if it solves the issue on Android as well?
On most Unix it's UB to touch TLS after fork. Even if we have static TLS, accessing it might cause [^1] to be be called, and that function has paths where it allocates memory, takes locks, etc. That is, this is probably not a specific issue with QNX/Android. [^1]: At least on ELF, although I believe this is broadly true for Mach-O as well.
Code change:
<ins> error[E0644]: closure/coroutine type that references itself --> $DIR/cyclic_type_ice.rs:3:7 | LL |     f(f); |       ^ cyclic type of infinite size | = note: closures cannot capture themselves or take themselves as argument; this error may be the result of a recent compiler bug-fix, see issue #46062 <https://github.com/rust-lang/rust/issues/46062> for more information error[E0057]: this function takes 2 arguments but 1 argument was supplied --> $DIR/cyclic_type_ice.rs:3:5 | LL |     f(f); |     ^--- an argument is missing | note: closure defined here --> $DIR/cyclic_type_ice.rs:2:13 | LL |     let f = |_, _| (); |             ^^^^^^ help: provide the argument | LL |     f(/*  */, /*  */); |      ~~~~~~~~~~~~~~~~ error: aborting due to 2 previous errors Some errors have detailed explanations: E0057, E0644. For more information about an error, try `rustc --explain E0057`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'', 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
Code change:
"concatenates all document attributes into one document attribute"), ("strip-private", passes::strip_private, "strips all private items from a crate which cannot be seen externally"), <ins> ("strip-priv-imports", passes::strip_priv_imports, "strips all private import statements (`use`, `extern crate`) from a crate"), </ins> ]; const DEFAULT_PASSES: &'static [&'static str] = &[

Related discussion:
text: Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?
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: 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:
<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: 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:
<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: 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.