Add new `doc(attribute = "...")` attribute
Fixesrust-lang/rust#141123.
The implementation and purpose of this new `#[doc(attribute = "...")]` attribute is very close to `#[doc(keyword = "...")]`. Which means that luckily for us, most of the code needed was already in place and `@Noratrieb` nicely wrote a first draft that helped me implement this new attribute very fast.
Now with all this said, there is one thing I didn't do yet: adding a `rustdoc-js-std` test. I added GUI tests with search results for attributes so should be fine but I still plan on adding one for it once documentation for builtin attributes will be written into the core/std libs.
You can test it [here](https://rustdoc.crud.net/imperio/doc-attribute-attribute/foo/index.html).
cc `@Noratrieb` `@Veykril`
Don't export them from cdylibs. There is no need to do so and it
complicates exported_non_generic_symbols. In addition the GCC backend
likely uses different symbols and may potentially not even need us to
explicitly tell it to export the symbols it needs.
We have a ui test to ensure we emit an error if we encounter too big
enums. Before this fix, compiling the test with `-Cdebuginfo=2` would
not include the span of the instantiation site, because the error is
then emitted from a different code path that does not include the span.
Propagate the span to the error also in the debuginfo case, so the test
passes regardless of debuginfo level.
When determining if a trait has no entries for the purposes of omitting vptrs from subtrait vtables, consider its transitive supertraits' entries, instead of just its own entries.
When determining if a non-first supertrait vptr can be omitted from a subtrait vtable, check if the supertrait or any of its (transitive) supertraits have methods, instead of only checking if the supertrait itself has methods.
This fixes the soundness issue where a vptr would be omitted for a supertrait with no methods but that itself had a supertrait with methods, while still optimizing the case where the supertrait is "truly" empty (it has no own vtable entries, and none of its (transitive) supertraits have any own vtable entries).
Fixes <https://github.com/rust-lang/rust/issues/145752>
-----
Old description:
~~Treat all non-auto traits as non-empty (possibly having methods) for purposes of determining if we need to emit a vptr for a non-direct supertrait (and for new "sibling" entries after a direct or non-direct supertrait).~~
This fixes (I believe) the soundness issue, ~~but regresses vtable sizes and possibly upcasting perf in some cases when using trait hierarchies with empty non-auto traits (see `tests/ui/traits/vtable/multiple-markers.stderr`) since we use vptrs in some cases where we could re-use the vtable.~~
Fixes <https://github.com/rust-lang/rust/issues/145752>
Re-opens (not anymore) <https://github.com/rust-lang/rust/issues/114942>
Should not affect <https://github.com/rust-lang/rust/issues/131813> (i.e. the soundness issue is still fixed, ~~though the relevant vtables in the `trait Evil` example will be larger now~~)
cc implementation history <https://github.com/rust-lang/rust/pull/131864> <https://github.com/rust-lang/rust/pull/113856>
-----
~~It should be possible to check if a trait has any methods from itself *or* supertraits (instead of just from itself), but to fix the immediate soundness issue, just assume any non-auto trait could have methods. A more optimistic check can be implemented later (or if someone does it soon it could just supercede this PR 😄).~~ Done in latest push
`@rustbot` label A-dyn-trait F-trait_upcasting
`const`ify (the unstable) `str::as_str`
Tracking issue: rust-lang/rust#130366
The method was not initially marked `const` presumably because it is only useful with `Deref`. But now that const traits seem to be a thing that can actually become real, why not make it `const`?
PR `const`ifying `Deref`: rust-lang/rust#145279
Rename `Location::file_with_nul` to `file_as_c_str`
This renames the method to be consistent with the ongoing T-libs-api FCP found at https://github.com/rust-lang/rust/issues/141727#issuecomment-3228016708.
I did not rename the unstable feature as we are going to be stabilizing it soon anyway. This will probably break RfL, so it will require an updated commit hash for the Linux Kernel that I will add here soon.
r? `@Amanieu`
compiletest: Remove several remnants of the old libtest-based executor
I noticed a few bits of low-hanging cleanup that are possible now that the non-libtest executor is well and truly established.
No source fixes
This PR started as a fix for a rendering bug that [got noticed in #143661](https://github.com/rust-lang/rust/pull/143661#discussion_r2199109530), but turned into a fix for any rendering bugs related to files with no source.
- Don't add an end column separator after a file with no source
- Add column separator before secondary messages with no source
- Render continuation between no source labels
Before
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
╰╴
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
╰ note: private field
│
╰ note: private field
```
After
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╰╴
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
├ note: private field
│
╰ note: private field
```
Note: This PR also makes it so `rustc` and `annotate-snippets` match in these cases
Remove unnecessary `[dependencies.unicode-properties]` entries.
The Cargo style guide says to put dependencies on a single line if they fit.
r? `@jdonszelmann`
Fix STD build failing for target_os = "espidf"
A regression from rust-lang/rust#142938
cc `@lolbinarycat`
cc `@ibraheemdev`
ESP-IDF (and a few other embedded Tier-3 systems) is considered `cfg(unix)`, but it does not have the `O_NOFOLLOW` flag because neither of its three supported filesystems (FATFS, LitteLF and Spiffs) has symbolic links in the first place.
What this fix does is to keep the `set_permissions_nofollow` method available and non-failing for ESP-IDF, but it behaves as if no `O_NONFOLLOW` was set. This should be fine as there is nothing to follow in the first place, as there are no symbolic links there.
EDIT: Also added the same fix for Horizon, as requested by `@Meziu.`
Add assembly test for `-Zreg-struct-return` option
r? `@tgross35`
As discussed in rust-lang/rust#145309 with `@tgross35` and `@ojeda,` I added assembly tests for the `-Zreg-struct-return` option verifying that it changes the ABI from hidden pointer to register-return on x86_32.
The test covers:
- Direct struct construction, showing register return vs hidden pointer
- External function calls returning structs, showing ABI mismatch handling
Different memory layouts affect ABI mismatch handling, but register returns use the same register allocation regardless of struct field layout (apart from the fact that they use smaller registers for smaller structs, of course).
[Here](https://godbolt.org/z/dcW6rnMG3) is a compiler explorer with 2 examples. Let me know if there is anything more I could add. Since register returns only happen for structs up to the size of 2 registers, I figured testing the pivot value (8 bytes) would be most critical.
Use captures(address) instead of captures(none) for indirect args
While provenance cannot be captured through these arguments, the address / object identity can.
Fixes https://github.com/rust-lang/rust/issues/137668.
r? `@ghost`
