c-variadic: bpf and spirv do not support c-variadic definitions
tracking issue: https://github.com/rust-lang/rust/issues/44930
Emit a nice error message on bpf and spirv targets when a c-variadic function is defined. Spirv also does not support c-variadic calls, bpf appears to allow them.
r? ```@workingjubilee```
Disable native-lib for x check miri
This reduces check times for miri from 2m15s to 20s. And reduces check times for miri with --compile-time-deps from 1m50s to 7s. This makes rust-analyzer start a lot faster after switching branches.
r? ```@RalfJung```
Additional test for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: https://github.com/rust-lang/rust/issues/149069
Accepted ACP: https://github.com/rust-lang/libs-team/issues/695#issuecomment-3549284861
Adds an additional runtime test for `uN::gather_bits` and `uN::scatter_bits` in coretests. They are each other's inverses in a sense, so a shared test can test both with relative ease.
I plan to follow up with optimized implementations for these functions.
reword error for invalid range patterns
For half-open ranges, specifies that the upper bound cannot be the minimum.
Also specify that this only applies to range patterns and not also expressions.
Fixesrust-lang/rust#149165
CTFE: avoid emitting a hard error on generic normalization failures
Fixesrust-lang/rust#149081.
The fix is quite unsatisfying and should not be necessary, cc rust-lang/rust#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs.
cc ````@rust-lang/types```` I think we should try to fix issue rust-lang/rust#149283 in the near future and then remove this hack again.
I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this:
- we only fetch the MIR in the `eval_to_allocation_raw` query
- figuring out which MIR to use is hard
- dealing with trivial consts is annoying
- need to resolve instances for associated consts
- implementing this by hand is hard
- inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness
- `try_normalize_after_erasing_regions` generally does two things
- deal with ambiguity after inlining
- deal with error tainting issues (please don't, we should stop doing that)
- CTFE could be changed to always silently ignore normalization failures if we're in a generic body
- hides actual bugs <- went with this option
r? types
std: don't call `current_os_id` from signal handler
`current_os_id` is not always async-signal-safe depending on the platform, hence it may not be called from the SIGSEGV handler. Instead, store the thread ID along with the thread name during setup. With rust-lang/rust#144465 merged, this information is available even before the thread main function.
Use `TypingMode::PostAnalysis` in `try_evaluate_const`
As mentioned in https://github.com/rust-lang/rust/pull/148698#discussion_r2541882341, we should use ``TypingMode::PostAnalysis`` for that path.
````@BoxyUwU```` prefer the match in ``try_evaluate_const`` to be exhaustive, so I also included that in this PR :3
Fix ICE when applying test macro to crate root
This PR does a couple of things. First of all, I found [an ICE](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a733a7f3d223e1a9712e44b571f3e5cf) that happens when applying `#![core::prelude::v1::test]` to the crate root. This is caused by the test macro not expanding to an item when `--test` isn't applied. For the crate root, that means it deletes the crate....
The fix now first does target checking, and only if the target is valid discards the item when `--test` isn't applied. The discarding is, I think, important for perf.
The problem with this PR is that it means that `#[test]` applied to structs previously would give no errors unless `--test` is applied! That sounds like a bug to me, but maybe we should crater run it just in case, since technically that's a breaking change. Errors in such items wouldn't be reported previously.
Also fixed a smol diagnostics bug with `#[bench]`'s error messages refering to `#[test]` accidentally.
r? noratrieb (since I already explained you a bunch, feel free to re-assign)
Fixes https://github.com/rust-lang/rust/issues/114920
Revert #149516 because it caused dist to pick up x86_64
`libwinpthreads.dll` dependency, resulting in broken toolchain.
This reverts commit 5afd8ff8df, reversing
changes made to 7cb02f9752.
This reduces check times for miri from 2m15s to 20s. And reduces check
times for miri with --compile-time-deps from 1m50s to 7s. This makes
rust-analyzer start a lot faster after switching branches.
linker: Remove special case for `rust-lld` in `detect_self_contained_mingw`
`rust-lld` is supposed to live inside sysroot, so it doesn't change the behavior of the function, only removes a potential micro-optimization.
https://github.com/rust-lang/rust/pull/149178#issuecomment-3570619496
r? `@mati865`
Various never type test improvements
I want to make sure that the never type ui tests are actually sensible, and to do so I'm trying to clean them up. This mainly adds comments explaining test purposes and removes outdated stuff.
I imagine best reviewed commit-by-commit, I tried to write useful descriptions and group things into small commits.
cc `@lcnr` (I removed `fallback`/`nofallback` terminology in b5f82d4716d0d978b89034c902f88e2d449da636)
Rename supertrait item shadowing lints
This follows the lang team decision [here](https://github.com/rust-lang/rust/pull/148605#issuecomment-3525414326) and renames:
- `supertrait_item_shadowing_definition` to `shadowing_supertrait_items`
- `supertrait_item_shadowing_usage` to `resolving_to_items_shadowing_supertrait_items`
The lint levels are left unchanged as allow-by-default until stabilization.
Fix std::mem::drop rustdoc misleading statement
This is a bit misleading, we were discussing this with our Rust team and some people could think that the compiler does some special magic for this specific function and that's not true or well the compiler does something special but for every function.
The reality according to my understanding is that this is a normal function that takes ownership of the given value and as with every other function mir building injects Drop Terminators , drop elaboration refines this and then we would insert the corresponding drop glue, then potentially calling Drop::drop.
Not sure if it would be best to remove the sentence as this PR does or explaining something along the lines of the previous text.
Remove an outdated test
This... is a weird test.
It has two impls:
- `impl<T> From<Foo<T>> for Box<T>` (commented out, more on that later), and
- `impl<T> Into<Vec<T>> for Foo<T>`
The idea of that test is to show that the first impl doesn't compile, but the second does, thus `TryFrom` should be using `Into` and not `From` (because `Into` is more general, since the `From` impl doesn't compile).
However:
1. The types are different -- `Box` vs `Vec`, which is significant b/c `Box` is fundamental
2. The commented out impl actually compiles! (which wasn't detected b/c it's commented out :\ )
Here is a table for compilation of the impls:
| | `Vec` | `Box` |
|--------|--------------|----------------|
| `From` | since 1.41.0 | never |
| `Into` | always | not since 1.28 |
[godbolt used to test this](https://godbolt.org/z/T38E3jGKa)
Order of events:
1. in `1.28` the `incoherent_fundamental_impls` lint becomes deny by default (this is *not* mentioned in the changelog yay)
2. `1.32` changed absolutely nothing, even though this version is credited in the test
3. the test was added (I'm not exactly sure when) (see https://github.com/rust-lang/rust/pull/56796)
4. in `1.41` coherence was relaxed to allow `From`+`Vec` to compile
To conclude: since `1.41` this test does nothing (and before that it was written in a way which did not detect this change). It looks to me like today (since `1.41`) we *could* bound `TryFrom` impl with `From` (but now it'd be a useless breaking change of course).
Am I missing anything? Is there a useful version of this test that could be written?
Example
---
```rust
fn main() {
let x = &$0
}
```
**Before this PR**
```rust
fn main() {
let x = &loop {
$0
}
}
```
**After this PR**
```rust
fn main() {
let x = &loop {
$0
};
}
```
added default_uwtables=true to aarch64_unknown_none targets
This patch adds DWARF unwinding tables by default for `aarch64-unknown-none` and `aarch64-unknown-none-softfloat` targets. By implication, the `core` library for these targets will be built with unwinding tables. These tables are often useful, and are especially needed for backtracing through `core` on embedded targets. The tables can be turned off for user compilation with `-C force-unwind-tables=no` if desired.
(I am the lead maintainer for these targets in the Rust Embedded Working Group, and have discussed this with REWG.)
Remove initialized-bytes tracking from `BorrowedBuf` and `BorrowedCursor`
As discussed extensively in libs-api, the initialized-bytes tracking primarily benefits calls to `read_buf` that end up initializing the buffer and calling `read`, at the expense of calls to `read_buf` that *don't* need to initialize the buffer. Essentially, this optimizes for the past at the expense of the future. If people observe performance issues using `read_buf` (or something that calls it) with a given `Read` impl, they can fix those performance issues by implementing `read_buf` for that `Read`.
Update the documentation to stop talking about initialized-but-unfilled bytes.
Remove all functions that just deal with those bytes and their tracking, and remove usage of those methods.
Remove `BorrowedCursor::advance` as there's no longer a safe case for advancing within initialized-but-unfilled bytes. Rename `BorrowedCursor::advance_unchecked` to `advance`.
Update tests.
r? ``@Amanieu``
