- fixup `BTreeMap` gdb provider
- fixup `ManuallyDrop` natvis thingy
Now that `MaybeUninit` contains `ManuallyDrop` which contains
`MaybeDangling` (tbc this is the addition), we need to unwrap one more
layer.
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
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.
Bring back i686-pc-windows-gnullvm target
rust-lang/rust#148751 inadvertently removed i686-pc-windows-gnullvm std build when migrating to native CI runners. Since this change was not agreed upon, we should bring back prebuilt std builds for that target.
There are a few runners that could do it: dist-aarch64-llvm-mingw, dist-x86_64-llvm-mingw, dist-various-1 and dist-various-2.
dist-x86_64-llvm-mingw already takes slightly over 2 hours, so the faster dist-aarch64-llvm-mingw is a better choice.
We can also use dist-various-x job, they don't have llvm-mingw toolchain, but it's trivial to install one.
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.
