Elide superfluous storage markers
Follow the existing strategy of omitting the storage markers for temporaries
introduced for internal usage when elaborating derefs and deref projections.
Those temporaries are simple scalars which are used immediately after being
defined and never have their address taken. There is no benefit from storage
markers from either liveness analysis or code generation perspective.
Add a missing test case for impl generic mismatch
This suggestion use different span depending on whether the method has generics or not, so I added a test case about the method with some generics.
Use par_body_owners for liveness
I did this refactoring while working on something else. Liveness is about bodies, there is no reason to use par_for_each_module here.
Tests are updated because things are visited in a different order. I checked diagnostics are same, just in a different (and IMO, better) order.
Suggest alternatives when trying to mutate a `HashMap`/`BTreeMap` via indexing
The error can be quite confusing to newcomers.
Fixes#100873.
I'm not so sure about the message, open to wording suggestions.
Coherence negative impls implied bounds
Fixes#93875
This PR is rebased on top of #100789 and it would need to include that one which is already r+ed.
r? ``@nikomatsakis``
cc ``@lcnr`` (which I've talked about 3222f420d9, I guess after you finish your reordering of modules and work with OutlivesEnvironmentEnv this commit can just be reverted).
sugg: take into count the debug formatting
Closes https://github.com/rust-lang/rust/issues/100648
This PR will fix a suggestion error by taking into consideration also the `:?` symbol and act in a different way
``@rustbot`` r? ``@compiler-errors``
N.B: I did not find a full way to test the change, any idea?
fluent: mandate slug names to be prefixed by crate name
This is currently only convention, but not actively checked for.
Additionally, improve error messages to highlight the path of the offending fluent file rather than the identifier preceding it.
This will conflict with #100671, so I'll leave it as draft until that's merged.
Do not re-parse function signatures to suggest generics
This PR uses the existing resolution rib infrastructure to channel the correct span information to suggest generic parameters. This allows to avoid re-parsing a function's source code.
Drive-by cleanup: this removes useless `FnItemRibKind` from late resolution ribs. All the use cases are already covered by `ItemRibKind` and `AssocItemRibKind` which have more precise semantics.
Rollup of 9 pull requests
Successful merges:
- #100382 (Make the GATS self outlives error take into GATs in the inputs)
- #100565 (Suggest adding a missing semicolon before an item)
- #100641 (Add the armv4t-none-eabi target to the supported_targets)
- #100789 (Use separate infcx to solve obligations during negative coherence)
- #100832 (Some small bootstrap cleanup)
- #100861 (fix ICE with extra-const-ub-checks)
- #100862 (tidy: remove crossbeam-utils)
- #100887 (Refactor part of codegen_call_terminator)
- #100893 (Remove out-of-context comment in `mem::MaybeUninit` documentation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use separate infcx to solve obligations during negative coherence
I feel like I fixed this already but I may have fixed it then forgot to push the branch...
Also fixes up some redundant param-envs being passed around (since they're already passed around in the `Obligation`)
Fixes#99662
r? ``@spastorino``
Make the GATS self outlives error take into GATs in the inputs
Before, the reasoning was that outlives should factor in to the outlives error, because that value is produced and inputs aren't. However, this is potentially confusing, and we can just require this for now and relax it later if we need. GATs in where clauses still don't count for the self outlives error, and I've added a test for that.
This now errors:
```rust
trait Input {
type Item<'a>;
//~^ missing required
fn takes_item<'a>(&'a self, item: Self::Item<'a>);
}
```
I've also added a test that this does not:
```rust
trait WhereClause {
type Item<'a>;
fn takes_item<'a>(&'a self) where Self::Item<'a>: ;
}
```
r? ``@compiler-errors``
UnreachableProp: Preserve unreachable branches for multiple targets
Before, UnreachablePropagation removed all unreachable branches. This was a pessimization, as it removed information about reachability that was used later in the optimization pipeline.
For example, this code
```rust
pub enum Two { A, B }
pub fn identity(x: Two) -> Two {
match x {
Two::A => Two::A,
Two::B => Two::B,
}
}
```
basically has `switchInt() -> [0: 0, 1: 1, otherwise: unreachable]` for the match. This allows it to be transformed into a simple `x`. If we remove the unreachable branch, the transformation becomes illegal.
This was the problem keeping `UnreachablePropagation` from being enabled, so we can enable it now.
Something similar already happened in #77800, but it did not show a perf improvement there. Let's try it again anyways!
Fixes#68105, although that issue has been fixed for a long time (see #77680).
Make some const prop mir-opt tests `unit-test`s
Most of these have no or only tiny diffs beyond line numbers being changed (would it make sense to not have line numbers in mir-opt tests?). Some things changed a bit, but I think it should all be fine, not sure though.
Expand potential inner `Or` pattern for THIR
Code assumed there wouldn't be a deeper `Or` pattern inside expanded `PatStack` this fixes it by looking for the `Or` pattern inside expanded `PatStack`.
A more ideal solution would be recursively doing this but I haven't found a good way to do that.
_fixes #97898_
Recover keywords in trait bounds
(_this pr was inspired by [this tweet](https://twitter.com/Azumanga/status/1552982326409367561)_)
Recover keywords in trait bound, motivational example:
```rust
fn f(_: impl fn()) {} // mistyped, meant `Fn`
```
<details><summary>Current nightly (3 needless and confusing errors!)</summary>
<p>
```text
error: expected identifier, found keyword `fn`
--> ./t.rs:1:15
|
1 | fn _f(_: impl fn()) {}
| ^^ expected identifier, found keyword
|
help: escape `fn` to use it as an identifier
|
1 | fn _f(_: impl r#fn()) {}
| ++
error: expected one of `:` or `|`, found `)`
--> ./t.rs:1:19
|
1 | fn _f(_: impl fn()) {}
| ^ expected one of `:` or `|`
error: expected one of `!`, `(`, `)`, `,`, `?`, `for`, `~`, lifetime, or path, found keyword `fn`
--> ./t.rs:1:15
|
1 | fn _f(_: impl fn()) {}
| -^^ expected one of 9 possible tokens
| |
| help: missing `,`
error: at least one trait must be specified
--> ./t.rs:1:10
|
1 | fn _f(_: impl fn()) {}
| ^^^^
```
</p>
</details>
This PR:
```text
error: expected identifier, found keyword `fn`
--> ./t.rs:1:15
|
1 | fn _f(_: impl fn()) {}
| ^^ expected identifier, found keyword
|
help: escape `fn` to use it as an identifier
|
1 | fn _f(_: impl r#fn()) {}
| ++
error[E0405]: cannot find trait `r#fn` in this scope
--> ./t.rs:1:15
|
1 | fn _f(_: impl fn()) {}
| ^^ help: a trait with a similar name exists (notice the capitalization): `Fn`
|
::: /home/waffle/projects/repos/rust/library/core/src/ops/function.rs:74:1
|
74 | pub trait Fn<Args>: FnMut<Args> {
| ------------------------------- similarly named trait `Fn` defined here
```
It would be nice to have suggestion in the first error like "have you meant `Fn` trait", instead of a separate error, but the recovery is deep inside ident parsing, which makes it a lot harder to do.
r? `@compiler-errors`
implied bounds: explicitly state which types are assumed to be wf
Adds a new query which maps each definition to the types which that definition assumes to be well formed. The intent is to make it easier to reason about implied bounds.
This change should not influence the user-facing behavior of rustc. Notably, `borrowck` still only assumes that the function signature of associated functions is well formed while `wfcheck` assumes that the both the function signature and the impl trait ref is well formed. Not sure if that by itself can trigger UB or whether it's just annoying.
As a next step, we can add `WellFormed` predicates to `predicates_of` of these items and can stop adding the wf bounds at each place which uses them. I also intend to move the computation from `assumed_wf_types` to `implied_bounds` into the `param_env` computation. This requires me to take a deeper look at `compare_predicate_entailment` which is currently somewhat weird wrt implied bounds so I am not touching this here.
r? `@nikomatsakis`
Use `AttrVec` more
In some places we use `Vec<Attribute>` and some places we use
`ThinVec<Attribute>` (a.k.a. `AttrVec`). This results in various points
where we have to convert between `Vec` and `ThinVec`.
This commit changes the places that use `Vec<Attribute>` to use
`AttrVec`. A lot of this is mechanical and boring, but there are
some interesting parts:
- It adds a few new methods to `ThinVec`.
- It implements `MapInPlace` for `ThinVec`, and introduces a macro to
avoid the repetition of this trait for `Vec`, `SmallVec`, and
`ThinVec`.
Overall, it makes the code a little nicer, and has little effect on
performance. But it is a precursor to removing
`rustc_data_structures::ThinVec` and replacing it with
`thin_vec::ThinVec`, which is implemented more efficiently.
r? `@spastorino`
Rework "point at arg" suggestions to be more accurate
Fixes#100560
Introduce a new set of `ObligationCauseCode`s which have additional bookeeping for what expression caused the obligation, and which predicate caused the obligation. This allows us to look at the _unsubstituted_ signature to find out which parameter or generic type argument caused an obligaton to fail.
This means that (in most cases) we significantly improve the likelihood of pointing out the right argument that causes a fulfillment error. Also, since this logic isn't happening in just the `select_where_possible_and_mutate_fulfillment()` calls in the argument checking code, but instead during all trait selection in `FnCtxt`, we are also able to point out the correct argument even if inference means that we don't know whether an obligation has failed until well after a call expression has been checked.
r? `@ghost`
In some places we use `Vec<Attribute>` and some places we use
`ThinVec<Attribute>` (a.k.a. `AttrVec`). This results in various points
where we have to convert between `Vec` and `ThinVec`.
This commit changes the places that use `Vec<Attribute>` to use
`AttrVec`. A lot of this is mechanical and boring, but there are
some interesting parts:
- It adds a few new methods to `ThinVec`.
- It implements `MapInPlace` for `ThinVec`, and introduces a macro to
avoid the repetition of this trait for `Vec`, `SmallVec`, and
`ThinVec`.
Overall, it makes the code a little nicer, and has little effect on
performance. But it is a precursor to removing
`rustc_data_structures::thin_vec::ThinVec` and replacing it with
`thin_vec::ThinVec`, which is implemented more efficiently.
rustdoc: Merge source code pages HTML elements together v2
This is the follow-up of https://github.com/rust-lang/rust/pull/100429.
I strongly recommend to review it one commit at a time because otherwise it's a lot at once.
For these ones, on each page, I run this JS: `document.getElementsByTagName('*').length`. The goal is to count the number of DOM elements. I took some pages that seemed big, but don't hesitate to check some others. I also added the "starting point" because it's quite nice to see how much the page was reduced thanks to these two PRs.
| file name | before #100429 | before this PR | with this PR | diff |
|-|-|-|-|-|
| std/lib.rs.html (source link on std crate page) | 3455 | 2332 | 1772 | 24% |
| alloc/vec/mod.rs.html (source on Vec type page) | 11012 | 5982 | 5833 | 2.5% |
| alloc/string.rs.html (source on String type page) | 10800 | 6010 | 5822 | 3.2% |
| std/sync/mutex.rs.html (source on Mutex type page) | 2953 | 2041 | 2038 | 0.1% |
So unsurprisingly, the more attributes you have, the bigger the difference.
You can test it [here](https://rustdoc.crud.net/imperio/reduce-span-v2/src/std/lib.rs.html).
cc ``````@jsha``````
r? ``````@notriddle``````
