```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt.rs:69:5
|
LL | match () { () => 1 } + match () { () => 1 }
| ^^^^^^^^^^^^^^^^^^^^ expected `()`, found integer
|
help: consider using a semicolon here
|
LL | match () { () => 1 }; + match () { () => 1 }
| +
help: alternatively, parentheses are required to parse this as an expression
|
LL | (match () { () => 1 }) + match () { () => 1 }
| + +
```
Parentheses are needed for the `match` to be unambiguously parsed as an expression and not a statement when chaining with binops that are also unops.
I.e. the type definition, then a single inherent `impl` block, then the
trait `impl` blocks.
The lack of sensible ordering here has bugged me for some time.
Remove TmpLayout in layout_of_enum
09a3846 from <https://github.com/rust-lang/rust/pull/103693> made LayoutData be owned instead of interned in `Variants::Multiple::variants`[^1], so there's no need for `TmpLayout` in layout_of_enum anymore, and we can just store the variants' layouts directly in the prospective `LayoutData`s' `variants` fields.
This should have no effect on semantics or layout.
(written as part of rust-lang/rust#145337 but not related to the layout optimizations in that PR)
[^1]: see line 1154 of `compiler/rustc_target/src/abi/mod.rs` in the linked commit; `Variants::Multiple::variants` effectively changed from `IndexVec<.., Layout<'tcx>>` to `IndexVec<.., LayoutData>` where the `LayoutData`s are not interned as `Layout`s (`LayoutData` was at the time called `LayoutS`)
Switch next solver to use a specific associated type for trait def id
The compiler just puts `DefId` in there, but rust-analyzer uses different types for each kind of item.
See [the Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Implmentating.20New.20Trait.20Solver/near/534329794). In short, it will be a tremendous help to r-a to use specific associated types, while for the solver and the compiler it's a small change. So I ported `TraitId`, as a proof of concept and it's also likely the most impactful.
r? types
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#142472 (Add new `doc(attribute = "...")` attribute)
- rust-lang/rust#145368 (CFI: Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`)
- rust-lang/rust#145853 (Improve error messages around invalid literals in attribute arguments)
- rust-lang/rust#145920 (bootstrap: Explicitly mark the end of a failed test's captured output)
- rust-lang/rust#145937 (add doc-hidden to exports in attribute prelude)
- rust-lang/rust#145965 (Move exporting of profiler and sanitizer symbols to the LLVM backend)
r? `@ghost`
`@rustbot` modify labels: rollup
Move exporting of profiler and sanitizer symbols to the LLVM backend
Only the LLVM backend needs those specific symbols exported and it only needs them to be exported for LTO, not from cdylibs in general.
Improve error messages around invalid literals in attribute arguments
r? `@jdonszelmann`
This previously created two errors, which is a bit ugly and the second one didn't add any value
Blocked on https://github.com/rust-lang/rust/pull/143193
CFI: Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`
Fixrust-lang/rust#142284 by ensuring that `#![no_builtins]` crates can still emit bitcode when proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto) is used.
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.
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
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`
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`
rustdoc: a few micro-optimizations targeted at build_impl
Unsure if these will be anything substantial, but the first one at least should git rid of quite a few branches, second one unsure if it's worth it.
r? `@GuillaumeGomez`
