jiebi/CodeConvo huggingface dataset:
Code change:
- Several unsupported `./configure` options have been removed: `optimize`, `parallel-compiler`. These can still be enabled with `--set`, although it isn't recommended. - `remote-test-server`'s `verbose` argument has been removed in favor of the `--verbose` flag - `remote-test-server`'s `remote` argument has been removed in favor of the `--bind` flag. Use `--bind 0.0.0.0:12345` to replicate the behavior of the `remote` argument. <ins> - `x.py fmt` now formats only files modified between the merge-base of HEAD and the last commit in the master branch of the rust-lang repository and the current working directory. To restore old behaviour, use `x.py fmt .`. The check mode is not affected by this change. [#105702](https://github.com/rust-lang/rust/pull/105702) </ins> ### Non-breaking changes

Related discussion:
text: Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:macro_with_super_1.rs #[macro_use] extern crate macro_with_super_1; declare!(); fn main() { bbb::ccc(); } </ins>

Related discussion:
text: Macro definitions encoded to the metadata do not preserve the identifier style, thus certain paths break down.
Nice catch. I was afraid something like this would happen... Really a bug in pretty printing, as it doesn't preserve the ident style. This is what we get for hacking contextual lexer information into the token stream...
The original example now compiles fine, but then I'm not sure about tomaka/android-rs-glue. is this issue still relevant?
I didn't test myself, but reported that it's fixed.
Yeah it looks like this has been fixed, yay!
Code change:
/// # Examples /// /// ```rust <del> /// #![feature(slice_from_raw_parts)] </del> /// use std::ptr; /// /// // create a slice pointer when starting out with a pointer to the first element <del> /// let mut x = [5, 6, 7]; /// let ptr = &mut x[0] as *mut _; /// let slice = ptr::slice_from_raw_parts_mut(ptr, 3); </del> <ins> /// let x = [5, 6, 7]; /// let ptr = x.as_ptr(); /// let slice = ptr::slice_from_raw_parts(ptr, 3); </ins> /// assert_eq!(unsafe { &*slice }[2], 7); /// ``` #[inline] <del> #[unstable(feature = "slice_from_raw_parts", reason = "recently added", issue = "36925")] </del> <ins> #[stable(feature = "slice_from_raw_parts", since = "1.42.0")] </ins> #[rustc_const_unstable(feature = "const_slice_from_raw_parts", issue = "67456")] pub const fn slice_from_raw_parts<T>(data: *const T, len: usize) -> *const [T] { unsafe { Repr { raw: FatPtr { data, len } }.rust }

Related discussion:
text: In stable Rust, the only way to get a with an arbitrary length is through . Unfortunately, that function returns a , which makes it very dubious to use with arbitrary raw pointers.
Given that isn't defined for , what would be the value of being able to create ?
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in enough to invoke UB if the pointer is invalid?
If the reference is , then this is insta-UB for sure.
Is there anything holding [] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation. cc If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at . Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use or to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my function into and , but so far, it works fine with one operating over , and it'd be sad to have the / split hanging around even after these functions stabilize (assuming they can)).
I don't recall any reason that cannot be stabilized.
The implementation PR used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
By the way, would also cover this :)
Code change:
<ins> error[E0433]: failed to resolve: use of undeclared type `Baz` --> $DIR/issue-81508.rs:11:20 | LL |     let Baz: &str = ""; |         --- help: `Baz` is defined here, but is not a type LL | LL |     println!("{}", Baz::Bar); |                    ^^^ use of undeclared type `Baz` error[E0433]: failed to resolve: use of undeclared type `Foo` --> $DIR/issue-81508.rs:20:24 | LL |     use super::Foo; |         ---------- help: `Foo` is defined here, but is not a type LL |     fn function() { LL |         println!("{}", Foo::Bar); |                        ^^^ use of undeclared type `Foo` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </ins>

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
<ins> error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/move-generic-to-trait-in-method-with-params.rs:14:7 | LL |     1.bar::<i32>(0); |       ^^^ expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/move-generic-to-trait-in-method-with-params.rs:4:8 | LL |     fn bar(&self, _: T); |        ^^^ help: consider moving this generic argument to the `Foo` trait, which takes up to 1 argument | LL |     Foo::<i32>::bar(1, 0); |     ~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     1.bar::<i32>(0); LL +     1.bar(0); | error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </ins>

Related discussion:
text: Repros on the /current nightly. But works (gives an error about mismatched number of generic arguments) on stable and beta. s/o to for the minimal example. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label regression-from-stable-to-nightly
Regressed in (nightly-2022-09-02), presumably , though seems to have already made the connection to that PR anyways :-)
Code change:
// Remember return type so that regionck can access it later. let fn_sig_tys: Vec<ty::t> = <del> arg_tys.iter() .chain([ret_ty].iter()) .map(|&ty| ty) .collect(); </del> <ins> arg_tys.iter().chain([ret_ty].iter()).map(|&ty| ty).collect(); </ins> debug!("fn-sig-map: fn_id={} fn_sig_tys={}", fn_id, fn_sig_tys.repr(tcx)); <del> inherited.fn_sig_map .borrow_mut() .insert(fn_id, fn_sig_tys); </del> <ins> inherited.fn_sig_map.borrow_mut().insert(fn_id, fn_sig_tys); </ins> { let mut visit = GatherLocalsVisitor { fcx: &fcx, };

Related discussion:
text: The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
Code change:
"arm", "avr", "bpf", <ins> "csky", </ins> "hexagon", "loongarch", "m68k",

Related discussion:
text: In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.
Code change:
// Additionally, the top bit of GLOBAL_PANIC_COUNT (GLOBAL_ALWAYS_ABORT_FLAG) // records whether panic::always_abort() has been called.  This can only be // set, never cleared. <ins> // panic::always_abort() is usually called to prevent memory allocations done by // the panic handling in the child created by `libc::fork`. // Memory allocations performed in  a child created with `libc::fork` are undefined // behavior in most operating systems. // Accessing LOCAL_PANIC_COUNT in a child created by `libc::fork` would lead to a memory // allocation. Only GLOBAL_PANIC_COUNT can be accessed in this situation. This is // sufficient because a child process will always have exactly one thread only. // See also #85261 for details. </ins> // // This could be viewed as a struct containing a single bit and an n-1-bit // value, but if we wrote it like that it would be more than a single word,

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:
// Additionally, the top bit of GLOBAL_PANIC_COUNT (GLOBAL_ALWAYS_ABORT_FLAG) // records whether panic::always_abort() has been called.  This can only be // set, never cleared. <ins> // panic::always_abort() is usually called to prevent memory allocations done by // the panic handling in the child created by `libc::fork`. // Memory allocations performed in  a child created with `libc::fork` are undefined // behavior in most operating systems. // Accessing LOCAL_PANIC_COUNT in a child created by `libc::fork` would lead to a memory // allocation. Only GLOBAL_PANIC_COUNT can be accessed in this situation. This is // sufficient because a child process will always have exactly one thread only. // See also #85261 for details. </ins> // // This could be viewed as a struct containing a single bit and an n-1-bit // value, but if we wrote it like that it would be more than a single word,

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:
// Additionally, the top bit of GLOBAL_PANIC_COUNT (GLOBAL_ALWAYS_ABORT_FLAG) // records whether panic::always_abort() has been called.  This can only be // set, never cleared. <ins> // panic::always_abort() is usually called to prevent memory allocations done by // the panic handling in the child created by `libc::fork`. // Memory allocations performed in  a child created with `libc::fork` are undefined // behavior in most operating systems. // Accessing LOCAL_PANIC_COUNT in a child created by `libc::fork` would lead to a memory // allocation. Only GLOBAL_PANIC_COUNT can be accessed in this situation. This is // sufficient because a child process will always have exactly one thread only. // See also #85261 for details. </ins> // // This could be viewed as a struct containing a single bit and an n-1-bit // value, but if we wrote it like that it would be more than a single word,

Related discussion:
text: Since is stored in which is not a thread-local, maybe the program could abort before using any thread-local.
It can't do that and also print the payload, because printing the payload might itself panic, and the recursive panic needs to be detected.
Maybe instead there should be a which can return None to mean "this thread-local variable has not been initialised".
I think it might be possible to use a to avoid the allocation.
Do thread-local always avoid the allocation? I think they fall back to regular thread-locals on platforms where avoiding allocations is not (easily) possible.
The version of looks basically same as the non- version when using , which will likely allocate here: Maybe the panic count could be stored directly in rather than on the heap. But is itself safe after ? If it tries to hold a lock or something it's possible to deadlock.
Should this only occur on Android? It happened on QNX as well (not yet upstreamed, work in progress so I don't trust it yet), but I can also reproduce it on with a simple patch (disables thread local storage): Would this be a target spec where we would expect to succeed?
Interesting. To be honest, I'm not sure. I do know that modern libc doctrine is that allocation after fork is UB. The test case is checking that we can safely panic after fork, and abort, without UB. This ought to work due to . I think that every failure of this test case is a real bug. Solving those bugs is not so easy because the machinery inside panic uses thread-local state which apparently is really super hard to make work without allocating or taking locks.
Yes, allocating memory is UB, same as working with mutexes. In case our setups are okay (i.e. having and using fork etc.), I also see this is a bug. Maybe we don't need to fix the issue with the thread-local state (if at all possible): calls to get the number recursive panics and if we . : determines using --works determines number recursive panics using TLS --allocates after --UB first: If it is true, it will always call -- the process will be killed very very soon by the OS In case of a recursion, a hardcoded-string is printed; otherwise additionally Do we really need to correctly determine a recursion, or can we allow "false positives"?
Code change:
// Additionally, the top bit of GLOBAL_PANIC_COUNT (GLOBAL_ALWAYS_ABORT_FLAG) // records whether panic::always_abort() has been called.  This can only be // set, never cleared. <ins> // panic::always_abort() is usually called to prevent memory allocations done by // the panic handling in the child created by `libc::fork`. // Memory allocations performed in  a child created with `libc::fork` are undefined // behavior in most operating systems. // Accessing LOCAL_PANIC_COUNT in a child created by `libc::fork` would lead to a memory // allocation. Only GLOBAL_PANIC_COUNT can be accessed in this situation. This is // sufficient because a child process will always have exactly one thread only. // See also #85261 for details. </ins> // // This could be viewed as a struct containing a single bit and an n-1-bit // value, but if we wrote it like that it would be more than a single word,

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:
use char::CharExt; try!(write!(f, "'")); for c in self.escape_default() { <del> try!(write!(f, "{}", c)); </del> <ins> try!(f.write_char(c)) </ins> } write!(f, "'") }

Related discussion:
text: Formatting a string containing special characters with usually prints them escaped i.e.. This snippet runs as expected in the . However on Windows, using both and , the is printed unescaped : From what I can gather,  only concerns itself with faulty surrogates and completely ignores special characters.