| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
preserve local style
|
|
|
|
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.
|
|
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
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
|
|
minor: Don't require a full `InferenceTable` for `CastTy`
|
|
with namespace
|
|
`is_primitive`, `is_keyword` and `is_attribute` methods
|
|
|
|
A DB is enough.
|
|
|
|
Namely, mir lowering, const eval and IDE things.
|
|
arg (#15583)
Closes rust-lang/rust-clippy#15576
changelog: [`numbered arg`] fix wrong suggestions for inline literal
following a numbered arg
|
|
numbered arg
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142727 (wasm: rm static mut)
- rust-lang/rust#143193 (Port `#[link]` to the new attribute parsing infrastructure )
- rust-lang/rust#144864 (No source fixes)
- rust-lang/rust#145913 (Add spin_loop hint for LoongArch)
- rust-lang/rust#145926 (compiletest: Remove several remnants of the old libtest-based executor)
- rust-lang/rust#145928 (Rename `Location::file_with_nul` to `file_as_c_str`)
- rust-lang/rust#145930 (`const`ify (the unstable) `str::as_str`)
- rust-lang/rust#145941 (Disable `integer_to_ptr_transmutes` suggestion for unsized types)
- rust-lang/rust#145953 (Update `icu_list` to 2.0)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
While working on rust-lang/rust-clippy#15229, I noticed a test case in
`map_identity` which avoids linting in the case where removing the
`.map()` would require the iterator variable to be made mutable. But
then I saw rust-lang/rust-clippy#14140, and thought I'd try to adapt its
approach, by suggesting both removing the `.map()` _and_ making the
variable mutable.
This is WIP only because I'm not sure about the very last
`diag.span_note` -- I think having a method chained immediately after
the `.map()` is the only case which requires adding `mut`, so it should
be safe to say that `method_requiring_mut` is always `Some`. I'd like to
do a lintcheck run to see if that's actually true.
@samueltardieu do you think this is a good approach? Maybe there are
more lints where we could lint + suggest making the variable mut,
instead of not linting?
changelog:`map_identity`: suggest making the variable mutable when
necessary
|
|
Add documentation for tracing
|
|
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
|
|
`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.
|
|
Add spin_loop hint for LoongArch
|
|
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
|
|
wasm: rm static mut
More https://github.com/rust-lang/rust/issues/125035. I'm not sure this is correct, but it compiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
