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.
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?
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``
std: sys: fs: uefi: Make time in FileAttr optional
At least on OVMF, some files copied over from linux file system seem to have invalid time (year = 1980 and everything else 0). Since Rust allows time to be optional, and we can return error, that seems to be the way to go for now.
`@rustbot` label +O-UEFI
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.
In `BTreeMap::eq`, do not compare the elements if the sizes are different.
Reverts rust-lang/rust#147101 in library/alloc/src/btree/
rust-lang/rust#147101 replaced some instances of code like `a.len() == b.len() && a.iter().eq(&b)` with just `a.iter().eq(&b)`, but the optimization that PR introduced only applies for `TrustedLen` iterators, and `BTreeMap`'s itertors are not `TrustedLen`, so this theoretically regressed perf for comparing large `BTreeMap`/`BTreeSet`s with unequal lengths but equal prefixes, (and also made it so that comparing two different-length `BTreeMap`/`BTreeSet`s with elements whose `PartialEq` impls that can panic now can panic, though this is not a "promised" behaviour either way (cc rust-lang/rust#149122))
Given that `TrustedLen` is an unsafe trait, I opted to not implement it for `BTreeMap`'s iterators, and instead just revert the change. If someone else wants to audit `BTreeMap`'s iterators to make sure they always return the right number of items (even in the face of incorrect user `Ord` impls) and then implement `TrustedLen` for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright).
Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using `Instant::elapsed`).
In release mode on stable the comparison takes ~23.68µs.
In release mode on beta/nightly the comparison takes ~48.351057ms.
At least on OVMF, some files copied over from linux file system seem
to have invalid time (year = 1980 and everything else 0). Since Rust
allows time to be optional and we can return error, that seems to be
the way to go for now.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
chore: Update annotate-snippets to 0.12.10
This PR updates `annotate-snippets` to `0.12.10`, which [includes a fix](756366223c/CHANGELOG.md (fixed)) that modifies some test output.
