Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete
I think they've graduated, since as far as I'm aware, they don't cause compiler crashes or unsoundness anymore.
Fix elaboration with associated type bounds
When computing a trait's supertrait predicates, do not add any associated type *trait* bounds to that list of supertrait predicates. This is because supertrait predicates are expected to have the same `Self` type as the trait.
For example, given:
```rust
trait Foo: Bar<Assoc: Send>
```
Before, we would compute that the supertrait predicates of `T: Foo` are `T: Bar` and `<T as Bar>::Assoc: Send`. However, the last bound is a trait predicate for a totally different type than `T`, and existing code that uses supertrait bounds such as vtable construction, closure fn signature deduction, etc. all rely on the invariant that we have a list of predicates for self type `T`.
Fixes#76593
The reason for all the extra diagnostic noise is that we're recomputing predicates with a different filter now. These diagnostics should be deduplicated for any end-user though.
---
This does bring up an interesting question -- is the predicate `<T as Bar>::Assoc: Send` an implied bound of `T: Foo`? Because currently the only bounds implied by a (non-alias) trait are its supertraits. I guess I could fix this too, but it would require even more changes, and I'm inclined to punt this question along.
Stabilize debugger_visualizer
This stabilizes the `debugger_visualizer` attribute (#95939).
* Marks the `debugger_visualizer` feature as `accepted`.
* Marks the `debugger_visualizer` attribute as `ungated`.
* Deletes feature gate test, removes feature gate from other tests.
Closes#95939
Add `ConstParamTy` trait
This is a bit sketch, but idk.
r? `@BoxyUwU`
Yet to be done:
- [x] ~~Figure out if it's okay to implement `StructuralEq` for primitives / possibly remove their special casing~~ (it should be okay, but maybe not in this PR...)
- [ ] Maybe refactor the code a little bit
- [x] Use a macro to make impls a bit nicer
Future work:
- [ ] Actually™ use the trait when checking if a `const` generic type is allowed
- [ ] _Really_ refactor the surrounding code
- [ ] Refactor `marker.rs` into multiple modules for each "theme" of markers
Don't validate constants in const propagation
Validation is neither necessary nor desirable.
The constant validation is already omitted at mir-opt-level >= 3, so there there are not changes in MIR test output (the propagation of invalid constants is covered by an existing test in tests/mir-opt/const_prop/invalid_constant.rs).
Add `#[no_coverage]` to the test harness's `fn main`
There are two main motivations for adding `#[no_coverage]` to the test harness's entry point:
- The entry point is trivial compiler-generated code that doesn't correspond to user source, and it always runs, so there's no value in instrumenting it for coverage.
- Because it has dummy spans, it causes the instrumentor implementation to emit invalid coverage mappings that confuse `llvm-cov` and result in strange coverage reports.
Fixes#110749.
Leave promoteds untainted by errors when borrowck fails
Previously, when borrowck failed it would taint all promoteds within the MIR body. An attempt to evaluated the promoteds would subsequently fail with spurious "note: erroneous constant used". For example:
```console
...
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:9
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:14
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:19
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:24
|
7 | a = &0 * &1 * &2 * &3;
| ^^
```
Borrowck failure doesn't indicate that there is anything wrong with promoteds. Leave them untainted.
Fixes#110856.
Make `mem::replace` simpler in codegen
Since they'd mentioned more intrinsics for simplifying stuff recently,
r? `@WaffleLapkin`
This is a continuation of me looking at foundational stuff that ends up with more instructions than it really needs. Specifically I noticed this one because `Range::next` isn't MIR-inlining, and one of the largest parts of it is a `replace::<usize>` that's a good dozen instructions instead of the two it could be.
So this means that `ptr::write` with a `Copy` type no longer generates worse IR than manually dereferencing (well, at least in LLVM -- MIR still has bonus pointer casts), and in doing so means that we're finally down to just the two essential `memcpy`s when emitting `mem::replace` for a large type, rather than the bonus-`alloca` and three `memcpy`s we emitted before this ([or the 6 we currently emit in 1.69 stable](https://rust.godbolt.org/z/67W8on6nP)). That said, LLVM does _usually_ manage to optimize the extra code away. But it's still nice for it not to have to do as much, thanks to (for example) not going through an `alloca` when `replace`ing a primitive like a `usize`.
(This is a new intrinsic, but one that's immediately lowered to existing MIR constructs, so not anything that MIRI or the codegen backends or MIR semantics needs to do work to handle.)
My type ascription
Oh rip it out
Ah
If you think we live too much then
You can sacrifice diagnostics
Don't mix your garbage
Into my syntax
So many weird hacks keep diagnostics alive
Yet I don't even step outside
So many bad diagnostics keep tyasc alive
Yet tyasc doesn't even bother to survive!
Close parentheses for `offset_of` in AST pretty printing
HIR pretty printing already handles it correctly.
This will conflict with #110694 but it seems like that PR is gonna take bit more time.
Test precise capture with a multi-variant enum and exhaustive patterns
Add test checking that it is possible to capture fields of a multi-variant enum, when remaining variants are visibly uninhabited (under the `exhaustive_patterns` feature gate).
Remove wrong assertion in match checking.
This assertions is completely misguided, introduced by https://github.com/rust-lang/rust/pull/108504. The responsible PR is on beta, nominating for backport.
Instead of checking that this is not a `&&`, it would make sense to check that neither arms of that `&&` is a `let`. This seems like a lot of code for unclear benefit.
r? `@saethlin`
Tweak await span to not contain dot
Fixes a discrepancy between method calls and await expressions where the latter are desugared to have a span that *contains* the dot (i.e. `.await`) but method call identifiers don't contain the dot. This leads to weird suggestions suggestions in borrowck -- see linked issue.
Fixes#110761
This mostly touches a bunch of tests to tighten their `await` span.
Previously, when borrowck failed it would taint all promoteds within the MIR
body. An attempt to evaluated the promoteds would subsequently fail with
spurious "note: erroneous constant used". For example:
```console
...
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:9
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:14
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:19
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:24
|
7 | a = &0 * &1 * &2 * &3;
| ^^
```
Borrowck failure doesn't indicate that there is anything wrong with
promoteds. Leave them untainted.
Add test checking that it is possible to capture fields of a
multi-variant enum, when remaining variants are visibly uninhabited
(under the `exhaustive_patterns` feature gate).
rustdoc: catch and don't blow up on impl Trait cycles
Fixes#110629
An odd feature of Rust is that `Foo` is invalid, but `Bar` is okay:
type Foo<'a, 'b> = Box<dyn PartialEq<Foo<'a, 'b>>>;
type Bar<'a, 'b> = impl PartialEq<Bar<'a, 'b>>;
To get it right, track every time rustdoc descends into a type alias, so if it shows up twice, it can be write the path instead of infinitely expanding it.
Don't accidentally ignore all output in `tests/run-make/coverage-reports` diffs
Because the literal pipe `|` character was not escaped, these regexes ended up accidentally ignoring every line in the coverage report output, so the tests would not fail even if the output was wrong.
An odd feature of Rust is that `Foo` is invalid, but `Bar` is okay:
type Foo<'a, 'b> = Box<dyn PartialEq<Foo<'a, 'b>>>;
type Bar<'a, 'b> = impl PartialEq<Bar<'a, 'b>>;
To get it right, track every time rustdoc descends into a type alias,
so if it shows up twice, it can be write the path instead of
infinitely expanding it.
rustdoc: Get `repr` information through `AdtDef` for foreign items
As suggested by `@notriddle,` this approach works too. The only downside is that the display of the original attribute isn't kept, but I think it's an acceptable downside.
r? `@notriddle`
Move most rustdoc-ui tests into subdirectories
This makes it easier to know where to add a new test, and makes the top-level directory less overwhelming.
Add test for warning-free builds of `core` under `no_global_oom_handling`
`tests/run-make/alloc-no-oom-handling` tests that `alloc` under `no_global_oom_handling` builds and is warning-free.
Do the same for `core` to prevent issues such as [1].
Link: https://github.com/rust-lang/rust/pull/110649 [1]
Fix Unreadable non-UTF-8 output on localized MSVC
Fixes#35785 by converting non UTF-8 linker output to Unicode using the OEM code page.
Before:
```text
= note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n
```
After:
```text
= note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj'
```
The difference is more dramatic if using a non-ascii language pack for Windows.
rustdoc: fix weird margins between Deref impl items
## Before
## After
## Description
In the old setup, if the dereffed-to item has multiple impl blocks, each one gets its own `div.impl-items` in the section, but there are no headers separating them. Since the last method in a `div.impl-items` has no bottom margin, and there are no margins between these divs, there is no margin between the last method of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets exactly one `div.impl-items`, no matter how many impl blocks it actually has.
