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.)
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.
Update tests for libtest `--format json`
This PR makes the test work on beta and stable, and adds a test ensuring the option is not available on beta and stable. Backported these commits from https://github.com/rust-lang/rust/pull/110414.
rustdoc: Add a new lint for broken inline code
This patch adds `rustdoc::unescaped_backticks`, a new rustdoc lint that will detect broken inline code nodes.
The lint woks by finding stray backticks and with some heuristics tries to guess where the second backtick might be missing.
Here is how it looks:
```rust
#![warn(rustdoc::unescaped_backticks)]
/// `add(a, b) is the same as `add(b, a)`.
pub fn add(a: i32, b: i32) -> i32 { a + b }
```
```text
warning: unescaped backtick
--> src/lib.rs:3:41
|
3 | /// `add(a, b) is the same as `add(b, a)`.
| ^
|
help: a previous inline code might be longer than expected
|
3 | /// `add(a, b)` is the same as `add(b, a)`.
| +
help: if you meant to use a literal backtick, escape it
|
3 | /// `add(a, b) is the same as `add(b, a)\`.
| +
```
If we can't get proper spans, for example if the doc comment comes from a macro expansion, we print the suggestion in help messages instead. Here's a [real-world example](https://docs.rs/tracing-subscriber/0.3.17/tracing_subscriber/layer/trait.Filter.html#method.max_level_hint):
```text
warning: unescaped backtick
--> /tracing-subscriber-0.3.17/src/layer/mod.rs:1400:9
|
1400 | / /// Returns an optional hint of the highest [verbosity level][level] that
1401 | | /// this `Filter` will enable.
1402 | | ///
1403 | | /// If this method returns a [`LevelFilter`], it will be used as a hint to
... |
1427 | | /// [`Interest`]: tracing_core::subscriber::Interest
1428 | | /// [rebuild]: tracing_core::callsite::rebuild_interest_cache
| |_____________________________________________________________________^
|
= help: a previous inline code might be longer than expected
change: Therefore, if the `Filter will change the value returned by this
to this: Therefore, if the `Filter` will change the value returned by this
= help: if you meant to use a literal backtick, escape it
change: [`rebuild_interest_cache`][rebuild] is called after the value of the max
to this: [`rebuild_interest_cache\`][rebuild] is called after the value of the max
```
You can find more examples [here](https://gist.github.com/lukas-code/7678ddf5c608aee97b3a669de80d3465).
A limitation of the current implementation is, that it cannot suggest removing misplaced backticks, for example [here](https://docs.rs/tikv-jemalloc-sys/0.5.3+5.3.0-patched/tikv_jemalloc_sys/fn.mallctl.html).
The lint is allowed by default ~~and nightly-only~~ for now, ~~but without a feature gate. This is similar to how `rustdoc::invalid_html_tags` and `rustdoc::bare_urls` were handled.~~
Improve niche placement by trying two strategies and picking the better result
Fixes#104807Fixes#105371
Determining which sort order is better requires calculating the struct size (so we can calculate the niche offset). But that in turn depends on the field order, so happens after sorting. So the simple way to solve that is to run the whole thing twice and pick the better result.
1st commit is just code motion, the meat is in the later ones.
Don't duplicate anonymous lifetimes for async fn in traits
`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.
This fixes (partially) #110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).
