rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg
r? ``@ytmimi`` and/or ``@calebcartwright``
cc ``@fmease``
I'm putting this on r-l/rust since it should fix the nightly rustfmt version. If you don't care about having this regression until the next rustfmt->rust sync, then I can move that PR over to r-l/rustfmt.
---
> Any idea why the formatting would have changed [from #119099]?
**Copied over explanation:**
This has to do with the weirdness of the way that `parse_macro_arg` works. Unlike parsing nonterminal args in a macro-by-example, it eagerly tries, for example, to parse a type without checking that the beginning token may begin a type:
bf967319e2/src/parse/macros/mod.rs (L54)
Contrast this to the nonterminal parsing code, which first checks that the nonterminal may begin with a given token:
ef71f1047e/compiler/rustc_parse/src/parser/nonterminal.rs (L47)
In rust-lang/rust#119099, ``@fmease`` implemented a change so that `const Tr` would be parsed as `dyn const Tr` (a trait object to a const trait) in edition 2015.
This is okay for the purposes of macros, because he explicitly made sure that `const` did not get added to the list of tokens that may begin a `:ty` nonterminal kind: https://github.com/rust-lang/rust/pull/119099#discussion_r1436996007
However, since rustfmt is not so careful about eagerly parsing macro args before checking that they're legal in macro position, this changed the way that the string of tokens is being parsed into macro args.
Allow any `const` expression blocks in `thread_local!`
This PR contains a rebase of the macro change from #116392, together with adding a test under library/std/tests.
Testing this feature by making the documentation's example code needlessly more complicated was not appropriate as pointed out in https://github.com/rust-lang/rust/pull/116392#pullrequestreview-1753097757.
Without the macro change, this new test would fail to build as follows:
```console
error: no rules expected the token `let`
--> library/std/tests/thread.rs:26:13
|
26 | let value = 1;
| ^^^ no rules expected this token in macro call
|
note: while trying to match meta-variable `$init:expr`
--> library/std/src/thread/local.rs:189:69
|
189 | ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
| ^^^^^^^^^^
```
Closes#116392.
`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`
https://github.com/rust-lang/rust/pull/119752 leveraged and overloaded `is_object_safe` to prevent an ICE, but accurate object safety information is needed for precise suggestions. This separates out `is_downgradable`, used for the ICE prevention, and `is_object_safe`, which returns to its original meaning.
Report unreachable subpatterns consistently
We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant.
r? ```@compiler-errors```
Make generic const type mismatches not hide trait impls from the trait solver
pulled out of https://github.com/rust-lang/rust/pull/119895
It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.
The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In #119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.
Fix deallocation with wrong allocator in (A)Rc::from_box_in
Deallocate the `Box` with the original allocator (via `&A`), not `Global`.
Fixes#119749
<details> <summary>Example code with error and Miri output</summary>
(Note that this UB is not observable on stable, because the only usable allocator on stable is `Global` anyway.)
Code ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=96193c2c6a1912d7f669fbbe39174b09)):
```rs
#![feature(allocator_api)]
use std::alloc::System;
// uncomment one of these
use std::rc::Rc;
//use std::sync::Arc as Rc;
fn main() {
let x: Box<[u32], System> = Box::new_in([1,2,3], System);
let _: Rc<[u32], System> = Rc::from(x);
}
```
Miri output:
```rs
error: Undefined Behavior: deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
--> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14
|
117 | unsafe { __rust_dealloc(ptr, layout.size(), layout.align()) }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
= note: BACKTRACE:
= note: inside `std::alloc::dealloc` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14: 117:64
= note: inside `<std::alloc::Global as std::alloc::Allocator>::deallocate` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:254:22: 254:51
= note: inside `<std::boxed::Box<std::mem::ManuallyDrop<[u32]>> as std::ops::Drop>::drop` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1244:17: 1244:66
= note: inside `std::ptr::drop_in_place::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>> - shim(Some(std::boxed::Box<std::mem::ManuallyDrop<[u32]>>))` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1: 507:56
= note: inside `std::mem::drop::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>>` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:992:24: 992:25
= note: inside `std::rc::Rc::<[u32], std::alloc::System>::from_box_in` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:1928:13: 1928:22
= note: inside `<std::rc::Rc<[u32], std::alloc::System> as std::convert::From<std::boxed::Box<[u32], std::alloc::System>>>::from` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:2504:9: 2504:27
note: inside `main`
--> src/main.rs:10:32
|
10 | let _: Rc<[u32], System> = Rc::from(x);
| ^^^^^^^^^^^
note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace
error: aborting due to 1 previous error
```
</details>
Refactor uses of `objc_msgSend` to no longer have clashing definitions
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).
Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
Motivation is to avoid issues with clashing definitions, like described in https://github.com/rust-lang/rust/issues/12707#issuecomment-1570735643 and https://github.com/rust-lang/rust/issues/46188#issuecomment-1288058453, CC ``@bjorn3.``
Fix -Zremap-path-scope typo
This fixes a documentation typo from #115214 where `-Zremap-path-prefix=object` should be `-Zremap-path-scope=object`.
```@rustbot``` label: +F-trim-paths
Don't actually make bound ty/const for RTN
Avoid creating an unnecessary non-lifetime binder when we do RTN on a method that has ty/const params.
Fixes#120208
r? oli-obk
add help message for `exclusive_range_pattern` error
Fixes#120047
this error
```
error[E0658]: exclusive range pattern syntax is experimental
--> src/lib.rs:3:9
|
3 | 0..42 => {},
| ^^^^^
|
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information
= help: use an inclusive range pattern, like N..=M
```
now includes a help message
Not sure of proper procedure here but this seemed like a good help message (used the one suggested in the original issue), if you have a idea for one that is better or something I missed please comment!
remote-test: use u64 to represent file size
Currently, triggering a transfer of data exceeding the size of 4294967295 bytes results in a panic on the `remote-test-server` as `io::copy(&mut file, dst) failed with Connection reset by peer (os error 104)`. This issue happens because the size is transmitted as u32 to `remote-test-server`.
First commit increases the supported file size. But I am not sure about its necessity — can we realistically encounter file sizes exceeding 4GB in builds, perhaps through some complicated configurations?
~The second commit adds a sanity check to avoid encountering the error `io::copy(&mut file, dst) failed with Connection reset by peer (os error 104)` on the `remote-test-server` side.~
std::net: bind update for using backlog as `-1` too.
Albeit not documented, macOs also support negative value for the backlog argument.
ref: 2ff845c2e0/bsd/kern/uipc_socket.c (L1061)
xous: misc fixes + add network support
This patchset makes several fixes to Xous support. Additionally, this patch adds networking support.
Many of these fixes are the result of the recent patch to get `unwinding` support merged. As a result of this patch, we can now run rust tests. As a result of these tests, we now have 729 tests passing:
```
failures:
env::tests::test
env::tests::test_self_exe_path
env::tests::vars_debug
env::tests::vars_os_debug
os::raw::tests::same
path::tests::test_push
path::tests::test_set_file_name
time::tests::since_epoch
test result: FAILED. 729 passed; 8 failed; 1 ignored; 0 measured; 0 filtered out; finished in 214.54s
```
In the course of fixing several tests and getting the test sequence to reliably run, several issues were found. This patchset fixes those issues.
exclude unexported macro bindings from extern crate
Fixes#119301
Macros that aren't exported from an external crate should not be defined.
r? ``@petrochenkov``
Our "true negative" detection assumes that if at least one std handle is a Windows console then no other handle will be a msys2 tty pipe. This turns out to be a faulty assumption in the case of `/dev/ptmx`.
Pack u128 in the compiler to mitigate new alignment
This is based on #116672, adding a new `#[repr(packed(8))]` wrapper on `u128` to avoid changing any of the compiler's size assertions. This is needed in two places:
* `SwitchTargets`, otherwise its `SmallVec<[u128; 1]>` gets padded up to 32 bytes.
* `LitKind::Int`, so that entire `enum` can stay 24 bytes.
* This change definitely has far-reaching effects though, since it's public.
Rollup of 9 pull requests
Successful merges:
- #118714 ( Explanation that fields are being used when deriving `(Partial)Ord` on enums)
- #119710 (Improve `let_underscore_lock`)
- #119726 (Tweak Library Integer Division Docs)
- #119746 (rustdoc: hide modals when resizing the sidebar)
- #119986 (Fix error counting)
- #120194 (Shorten `#[must_use]` Diagnostic Message for `Option::is_none`)
- #120200 (Correct the anchor of an URL in an error message)
- #120203 (Replace `#!/bin/bash` with `#!/usr/bin/env bash` in rust-installer tests)
- #120212 (Give nnethercote more reviews)
r? `@ghost`
`@rustbot` modify labels: rollup
Replace `#!/bin/bash` with `#!/usr/bin/env bash` in rust-installer tests
This allows the rust-installer tests to pass on NixOS
This change has [already been made](302ad2175d) for the actual installer, it appears that the tests were just forgotten.
Shorten `#[must_use]` Diagnostic Message for `Option::is_none`
This shortens the `#[must_use]` diagnostics displayed, in light of the [review comment](https://github.com/rust-lang/rust/pull/62431/files#r300819839) on when this was originally added.
