CI: rfl: move job forward to Linux v7.0
This version contains both of the workarounds we had, thus remove them as well.
r? @lqd @Kobzol
try-job: x86_64-rust-for-linux
@rustbot label A-rust-for-linux
@bors try
Check closure's constness validity in the constness query
fixesrust-lang/rust#155584
instead of checking during ast lowering, where it's not easily possible to obtain all the right information in time. While lowering an assoc item we don't know if the parent was a const trait or a const impl. Tracing this information is quite annoying, and complicates a lot of code, which checking here after the fact is trivial.
std: sys: process: uefi: Add program searching
- Follow UEFI Shell search flow to search for programs while launching.
- Tested using OVMF on QEMU.
@rustbot label +O-UEFI
Avoid Vec allocation in TyCtxt::mk_place_elem
`mk_place_elem` appends a single `PlaceElem` to an existing (interned) projection. The current implementation copies the projection into a fresh `Vec`, pushes the new element, and re-interns the slice, which allocates on every call.
Feed the elements through `mk_place_elems_from_iter` so that `CollectAndApply`'s hand-unrolled stack fast path (up to 9 elements, in `rustc_type_ir::interner`) kicks in for the common case of short projections and the `Vec` allocation is skipped entirely. The behavior is identical for longer projections (the fast path falls back to a `Vec` internally).
Fix heap overflow in slice::join caused by misbehaving Borrow
This code allocates a buffer using lengths calculated by calling `.borrow()` on some slices, and then copies them over after again calling `.borrow()`. There is no safety-reliable guarantee that these will return the same slices.
While this code calls `.borrow()` three times, only one of them is problematic: the others already use checked indexing.
I made the test a normal library test, but let me know if it should go elsewhere.
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.
Implement more traits for FRTs
From https://github.com/rust-lang/rust/pull/154927#discussion_r3068460955.
FRTs now implement the following traits: `Sized + Freeze + RefUnwindSafe + Send + Sync + Unpin + UnsafeUnpin + UnwindSafe + Copy + Debug + Default + Eq + Hash + Ord`.
Let me know if there is any trait missing.
I also removed the explicit `Send` and `Sync` impls, since commit cb37ee2c87 ("make field representing types invariant over the base type") made the auto-trait impl work even if `T: !Send` or `T: !Sync`. Very happy to see unsafe impls get dropped :)
Note that I used the reflection feature (cc @oli-obk) to print the actual field names in the debug implementation. I think this is a cool way to use it, but if it isn't ready for that, I'm happy to change it to the alternative implementation I gave in the note comment (it's essentially Mark's suggestion but printing `T`'s name instead of `Self`'s).
Since this is a library change, I'll give this to Mark; feel free to also take a look/leave comments, Oli :)
r? @Mark-Simulacrum
Make Rcs and Arcs use pointer comparison for unsized types
`Rc` and `Arc`s have an `Eq` implementation that first attempt to compare the pointers as an optimization. This, however, was not extended to DSTs, which is what this PR fixes.
Fixesrust-lang/rust#154998.
`std::io::Take`: Clarify & optimize `BorrowedBuf::set_init` usage.
Don't initialize `buf` if it was already initialized. Clarify safety comments.
Move the `buf.advance()` call to make the initialization more like
calling `buf.ensure_init()`, then clarify how the code here is an
optimized variant of `ensure_init`.
Fix requires_lto targets needing lto set in cargo
Targets that set `requires_lto = true` were not actually using lto when compiling with cargo by default. They needed an extra `lto = true` in `Cargo.toml` to work.
Fix this by letting lto take precedence over the `embed_bitcode` flag when lto is required by a target.
If both these flags would be supplied by the user, an error is generated. However, this did not happen when lto was requested by the target instead of the user.
Fixesrust-lang/rust#148514
Tracking issue: rust-lang/rust#135024
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.
Prefer `-1` for `None`
Currently we pick "weird" numbers like `1114112` for `None::<char>`. While that's not *wrong*, it's kinda *unnatural* -- a human wouldn't make that choice.
This PR instead picks `-1` for thinge like `None::<char>` -- like [clang's `WEOF`](https://github.com/llvm/llvm-project/blob/63ae74b78a11f6c61136dbc445652929389eb9ab/libc/include/llvm-libc-macros/wchar-macros.h#L15) -- and `None::<bool>` and such.
Any enums with more than one niched value (so not `Result` nor `Option`) remain as they were before. Also we continue to use `0` when that's possible -- `-1` is only preferred when zero *isn't* possible.
---
Inspired when someone in discord posted an example like this <https://rust.godbolt.org/z/W94s9qdYW> and I thought it was odd that we're currently picking `-9223372036854775808` to be the value to store to mark an `Option<Vec<_>>` as `None`. (Especially since that needs an 8-byte immediate on x64, and writing `-1` is only a 4-byte immediate.)
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.
bors