Avoid improper spans when `...` or `..=` is recovered from non-ASCII
- Fixes https://github.com/rust-lang/rust/issues/155799
Adjusting span endpoints by `BytePos(1)` is almost always bad news.
In this case, the code assumed that it was skipping over a single ASCII character. But in the presence of parser recovery from other non-ASCII characters this resulted in an ICE due to bad string indexing when emitting suggestions.
Cleanups to `AttributeExt`
r? @mejrs
- Makes some functions take `ast::Attribute` instead of `impl AttributeExt`
- Remove `deprecation_note` from `AttributeExt`, since the two implementations are basically seperate
Fix minor panic-unsoundness in CString::clone_into
`CString` must always contain a null byte, calling `mem::take` on its inner allocation puts it in an invalid state (causing UB if e.g. it hits `CString::drop`) that can be observed if the allocator panics.
Unfortunately, this solution allocates an intermediate 1-element `Box`. I'm not sure of a clean way to avoid that additional allocation; we could directly `realloc` if we want but it's tricky. Might be something we can do with `ManuallyDrop`.
I do have a gnarly miri test for this that uses a panicky allocator, but I'm not sure where it would go. Happy to push it up if someone has a suggestion.
Bug discovered by Rust Foundation Security using AI. I'm just helping with the patch as a member of wg-security-response. We do not believe this bug needs embargo, it is a soundness fix for hard-to-trigger unsoundness.
Suggest enclosing format string with `""` under special cases
This commit adds suggestions on enclosing format string with `""` when it falls into the following 3 cases: `{}`, `{:?}`, `{:#?}` as mentioned in rust-lang/rust#155508.
Currently, this commit only recognizes the above 3 cases. I wonder if we should generalize this to more cases, for example, appying this suggestion to `Block`s with only 0 or 1 `Stmt`, such as `{:#x}`, `{:^10}`, `{abc}`.
macro_metavar_expr_concat: explain why idents are invalid
Recently I've been playing around with `macro_metavar_expr_concat` and in the process wasted more time than I'd have liked on debugging my dodgy idents. This should make that experience much nicer going forward.
Move `std::io::RawOsError` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Related: https://github.com/rust-lang/rust/pull/154654
## Description
As a part of moving components of `std::io` into `alloc::io` and `core::io`, there will need to be a new home for the type `RawOsError`. In this PR, I propose moving it to `core::io`, and removing it from `std::sys`. I suspect this will be quite controversial as it is a platform dependent type, but this is not the only instance of a type being conditioned on `target_os` in `core` (e.g., `core::os` and `core::ffi`).
Since `RawOsError` is currently unstable, I think it's reasonable to make this move now, and worry about making it platform independent if/when it is stabilized (e.g., replacing it with a wrapper around `isize` on all platforms).
---
## Notes
* No AI tooling of any kind was used during the creation of this PR.
Windows: Cache the pipe filesystem handle
Updates the anonymous pipe handling based on feedback from @lhecker (see https://github.com/rust-lang/rust/pull/142517#discussion_r3065864262). This does two things:
1. Cache the handle to the pipe filesystem so we don't have to reopen it each time.
2. Use the `\Device\NamedPipe\` directly instead of the symlink to it.
* Suggest enclosing format string under special cases
This commit add suggestions about enclosing format string when it falls
into the following cases: `{}`, `{:?}`, `{:#?}`.
* Add HELP annotations in the UI test
std: maintain `CStringArray` null-termination even if `Vec::push` panics
Fixesrust-lang/rust#155748 by performing the `push` of the new null terminator before overwriting the previous one.
This commit expands the initialism UCRT on first use in the rusct book
chapter on the *-windows-gnullvm platform support, making the chapter
easier to understand. Microsoft, the originator of this technology in
Windows, expands it to Universal C Runtime[1]. The same expansion is
added to the chapter.
[1] https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146181 (Add intrinsic for launch-sized workgroup memory on GPUs)
- rust-lang/rust#154803 (Fix ICE from cfg_attr_trace )
- rust-lang/rust#155065 (Error on invalid macho section specifier)
- rust-lang/rust#155485 (Add an edge-case test for `--remap-path-prefix` for `rustc` & `rustdoc`)
- rust-lang/rust#155659 (cleanup, restructure and merge `tests/ui/deriving` into `tests/ui/derives`)
- rust-lang/rust#155676 ( Reject implementing const Drop for types that are not const `Destruct` already)
- rust-lang/rust#155696 (Add a higher-level API for parsing attributes)
- rust-lang/rust#155769 (triagebot.toml: Ping Enselic when tests/debuginfo/basic-stepping.rs changes)
- rust-lang/rust#155783 (Do not suggest internal cfg trace attributes)
Reject implementing const Drop for types that are not const `Destruct` already
fixesrust-lang/rust#155618
While there is no soundness or otherwise issue currently, this PR ensures that people get what they expect. It seems wrong to allow implementing `const Drop`, but then the type still can't be dropped at compile-time.
r? @fee1-dead
cleanup, restructure and merge `tests/ui/deriving` into `tests/ui/derives`
As a followup to https://github.com/rust-lang/rust/pull/155615, this PR deletes some outdated tests from these directories, splits up `ui/derives` into smaller directories to roughly group tests by the derive macros they use and moves over all tests from `ui/deriving` into `ui/derives`.
r? @Kivooeo
Error on invalid macho section specifier
The macho section specifier used by `#[link_section = "..."]` is more strict than e.g. the one for elf. LLVM will error when you get it wrong, which is easy to do if you're used to elf. So, provide some guidance for the simplest mistakes, based on the LLVM validation.
Currently compilation fails with an LLVM error, see https://godbolt.org/z/WoE8EdK1K.
The LLVM validation logic is at
https://github.com/llvm/llvm-project/blob/a0f0d6342e0cd75b7f41e0e6aae0944393b68a62/llvm/lib/MC/MCSectionMachO.cpp#L199-L203
LLVM validates the other components of the section specifier too, but it feels a bit fragile to duplicate those checks. If you get that far, hopefully the LLVM errors will be sufficient to get unstuck.
---
sidequest from https://github.com/rust-lang/rust/pull/147811
r? JonathanBrouwer
specifically, is this the right place for this sort of validation? `rustc_attr_parsing` also does some validation.
Add intrinsic for launch-sized workgroup memory on GPUs
Workgroup memory is a memory region that is shared between all
threads in a workgroup on GPUs. Workgroup memory can be allocated
statically or after compilation, when launching a gpu-kernel.
The intrinsic added here returns the pointer to the memory that is
allocated at launch-time.
# Interface
With this change, workgroup memory can be accessed in Rust by
calling the new `gpu_launch_sized_workgroup_mem<T>() -> *mut T`
intrinsic.
It returns the pointer to workgroup memory guaranteeing that it is
aligned to at least the alignment of `T`.
The pointer is dereferencable for the size specified when launching the
current gpu-kernel (which may be the size of `T` but can also be larger
or smaller or zero).
All calls to this intrinsic return a pointer to the same address.
See the intrinsic documentation for more details.
## Alternative Interfaces
It was also considered to expose dynamic workgroup memory as extern
static variables in Rust, like they are represented in LLVM IR.
However, due to the pointer not being guaranteed to be dereferencable
(that depends on the allocated size at runtime), such a global must be
zero-sized, which makes global variables a bad fit.
# Implementation Details
Workgroup memory in amdgpu and nvptx lives in address space 3.
Workgroup memory from a launch is implemented by creating an
external global variable in address space 3. The global is declared with
size 0, as the actual size is only known at runtime. It is defined
behavior in LLVM to access an external global outside the defined size.
There is no similar way to get the allocated size of launch-sized
workgroup memory on amdgpu an nvptx, so users have to pass this
out-of-band or rely on target specific ways for now.
Tracking issue: rust-lang/rust#135516
privacy: Assert that compared visibilities are (usually) ordered
And make "greater than" (`>`) the new primary operation for comparing visibilities instead of "is at least" (`>=`).
Do not modify resolver outputs during lowering
Split from https://github.com/rust-lang/rust/pull/142830
I believe this achieves the same thing as https://github.com/rust-lang/rust/pull/153656 but in a much simpler way.
This PR forces AST->HIR lowering to stop mutating resolver outputs. Instead, it manages a few override maps that only live during lowering and are dropped afterwards.
r? @petrochenkov
cc @aerooneqq
The test `tests/debuginfo/basic-stepping.rs` has a history of regressing
for subtle reasons, and has non-obvious expectations. So I'd like to
keep an extra eye on it.
Jonathan Brouwer