| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
Co-authored-by: Dennis Bonke <dennis@managarm.org>
|
|
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.
|
|
add doc-hidden to exports in attribute prelude
Seems to fix rust-lang/rust#145870, at least temporarily. The underlying problem of course is still there.
r? `@fmease`
<img width="653" height="167" alt="image" src="https://github.com/user-attachments/assets/b5a8094c-849e-4328-997d-b772f9aa4088" />
Fixes rust-lang/rust#145870
|
|
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`
Fix rust-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
Fixes rust-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`
|
|
All other sanitizer symbols are handled in prepare_lto already.
|
|
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.
|
|
The RFC only limits hyphens at the beginning of lines and not if they
are indented or embedded in other content.
Sticking to that approach was confirmed by the T-lang liason at
https://github.com/rust-lang/rust/issues/141367#issuecomment-3202217544
There is a regression in error message quality which I'm leaving for
someone if they feel this needs improving.
|
|
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.
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
r=compiler-errors
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 :smile:).~~ Done in latest push
`@rustbot` label A-dyn-trait F-trait_upcasting
|
|
with namespace
|
|
`is_primitive`, `is_keyword` and `is_attribute` methods
|
|
|
|
Update `icu_list` to 2.0
This updates the `icu_list` crate, which is used for error formatting, from 1.5 to 2.0.
|
|
Disable `integer_to_ptr_transmutes` suggestion for unsized types
This PR disables the machine-applicable `integer_to_ptr_transmutes` lint suggestion for unsized types, as [`std::ptr::with_exposed_provenance`](https://doc.rust-lang.org/std/ptr/fn.with_exposed_provenance.html) requires sized types.
We should probably mention [`std::ptr::from_raw_parts`](https://doc.rust-lang.org/std/ptr/fn.from_raw_parts.html) when it becomes stable.
Related to https://github.com/rust-lang/rust/issues/145935
|
|
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
|
|
Port `#[link]` to the new attribute parsing infrastructure
Ports `link` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#145382 (Add assembly test for `-Zreg-struct-return` option)
- rust-lang/rust#145746 (Fix STD build failing for target_os = "espidf")
- rust-lang/rust#145826 (Use AcceptContext in AttribueParser::check_target)
- rust-lang/rust#145894 (Ensure the coordinator thread terminates before its channels drop)
- rust-lang/rust#145946 (Remove unnecessary `[dependencies.unicode-properties]` entries.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove unnecessary `[dependencies.unicode-properties]` entries.
The Cargo style guide says to put dependencies on a single line if they fit.
r? `@jdonszelmann`
|
|
Ensure the coordinator thread terminates before its channels drop
Fixes rust-lang/rust#142949
Explanation: https://github.com/rust-lang/rust/issues/142949#issuecomment-3224573185
|
|
Use AcceptContext in AttribueParser::check_target
|
|
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`
|
|
The Cargo style guide says to put dependencies on a single line if they
fit.
|
|
|
|
|
|
|
|
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`
|
|
|
