Migrate rustc_ast_passes diagnostics to `SessionDiagnostic` and translatable messages (first part)
Doing a full migration of the `rustc_ast_passes` crate.
Making a draft here since there's not yet a tracking issue for the migrations going on.
`@rustbot` label +A-translation
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.
It was disabled because of pathological behaviour of LLVM in some
benchmarks. As of #77680, this has been fixed. The problem there was
that it caused pessimizations in some cases. These have now been fixed
as well.
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.
Replace most uses of `pointer::offset` with `add` and `sub`
As PR title says, it replaces `pointer::offset` in compiler and standard library with `pointer::add` and `pointer::sub`. This generally makes code cleaner, easier to grasp and removes (or, well, hides) integer casts.
This is generally trivially correct, `.offset(-constant)` is just `.sub(constant)`, `.offset(usized as isize)` is just `.add(usized)`, etc. However in some cases we need to be careful with signs of things.
r? ````@scottmcm````
_split off from #100746_
some general mir typeck cleanup
this pr contains the parts of #95763 which already work correctly.
the remaining commits of that PR have some issues which are more complex to fix.
r? types
Minor syntax and formatting update to doc comment on `find_vtable_types_for_unsizing`
I noticed the code examples on this function weren't formatted as code, and also the that the syntax for trait objects was out of date (or just incorrect). This should bring it up to date.
Deriving SessionDiagnostic on a type no longer forces that diagnostic to
be one of warning, error, or fatal. The level is instead decided when
the struct is passed to the respective Handler::emit_*() method.
Refactor: remove unnecessary string searchings
This patch removes unnecessary string searchings for checking if function arguments have `&` and `&mut`.
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""
This reverts commit 16e10bf81e (PR #77716).
The original original PR enabled `cdylib` builds for iOS. However this caused problems because:
> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types https://github.com/rust-lang/rust/pull/4881 as a result a lot of projects now broken on Rust 1.46
However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.
> I see that this got merged recently: https://github.com/rust-lang/cargo/issues/10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.
So summing up, I think this PR can be reverted in 1.64. 🤞
Reenable disabled early syntax gates as future-incompatibility lints
- MCP: https://github.com/rust-lang/compiler-team/issues/535
The approach taken by this PR is
- Introduce a new lint, `unstable_syntax_pre_expansion`, and reenable the early syntax gates to emit it
- Use the diagnostic stashing mechanism to stash warnings the early warnings
- When the hard error occurs post expansion, steal and cancel the early warning
- Don't display any stashed warnings if errors are present to avoid the same noise problem that hiding type ascription errors is avoiding
Commits are working commits, but in a coherent steps-to-implement manner. Can be squashed if desired.
The preexisting `soft_unstable` lint seems like it would've been a good fit, but it is deny-by-default (appropriate for `#[bench]`) and these gates should be introduced as warn-by-default.
It may be desirable to change the stash mechanism's behavior to not flush lint errors in the presence of other errors either (like is done for warnings here), but upgrading a stash-using lint from warn to error perhaps is enough of a request to see the lint that they shouldn't be hidden; additionally, fixing the last error to get new errors thrown at you always feels bad, so if we know the lint errors are present, we should show them.
Using a new flag/mechanism for a "weak diagnostic" which is suppressed by other errors may also be desirable over assuming any stashed warnings are "weak," but this is the first user of stashing warnings and seems an appropriate use of stashing (it follows the "know more later to refine the diagnostic" pattern; here we learn that it's in a compiled position) so we get to define what it means to stash a non-hard-error diagnostic.
cc `````@petrochenkov````` (seconded MCP)
Make `same_type_modulo_infer` a proper `TypeRelation`
Specifically, this fixes#100690 because we no longer consider a `ReLateBound` and a `ReVar` to be equal. `ReVar` can only be equal to free regions or static.
Add the diagnostic translation lints to crates that don't emit them
Some of these have a note saying that they should build on a stable compiler, does that mean they shouldn't get these lints? Or can we cfg them out on those?
Migrate "invalid variable declaration" errors to SessionDiagnostic
After seeing the great blog post on Inside Rust, I decided to try my hand at this. Just one diagnostic for now to get used to the workflow and to check if this is the way to do it or if there are any problems.
suggest `once_cell::Lazy` for non-const statics
Addresses https://github.com/rust-lang/rust/issues/100410
Some questions:
- removing the `if` seems to include too many cases (e.g. calls to non-const functions inside a `const fn`), but this code excludes the following case:
```rust
const FOO: Foo = non_const_fn();
```
Should we suggest `once_cell` in this case as well?
- The original issue mentions suggesting `AtomicI32` instead of `Mutex<i32>`, should this PR address that as well?
Mention `as_mut` alongside `as_ref` in borrowck error message
Kinda fixes#99426 but I guess that really might be better staying open to see if we could make it suggest `as_mut` in a structured way. Not sure how to change borrowck to know that info tho.
Rollup of 9 pull requests
Successful merges:
- #99576 (Do not allow `Drop` impl on foreign fundamental types)
- #100081 (never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn))
- #100208 (make NOP dyn casts not require anything about the vtable)
- #100494 (Cleanup rustdoc themes)
- #100522 (Only check the `DefId` for the recursion check in MIR inliner.)
- #100592 (Manually implement Debug for ImportKind.)
- #100598 (Don't fix builtin index when Where clause is found)
- #100721 (Add diagnostics lints to `rustc_type_ir` module)
- #100731 (rustdoc: count deref and non-deref as same set of used methods)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Lazily decode SourceFile from metadata
Currently, source files from foreign crates are decoded up-front from metadata.
Spans from those crates were matched with the corresponding source using binary search among those files.
This PR changes the strategy by matching spans to files during encoding. This allows to decode source files on-demand, instead of up-front. The on-disk format for spans becomes: `<tag> <position from start of file> <length> <file index> <crate (if foreign file)>`.
Don't fix builtin index when Where clause is found
Where clause shadows blanket impl for `Index` which causes normalization to not occur, which causes ICE to happen when we typeck.
r? `@compiler-errors`
Fixes#91633
never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn)
Judging from https://github.com/rust-lang/rust/issues/71668#issuecomment-1200317370 the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with `deny(unsafe_op_in_unsafe_fn)`, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly.
The first commit does the change, the 2nd does some cleanup.
Do not allow `Drop` impl on foreign fundamental types
`Drop` should not be implemented on `Pin<T>` even if `T` is local.
This does not trigger regular orphan rules is because `Pin` is `#[fundamental]`... but we don't allow specialized `Drop` impls anyways, so these rules are not sufficient to prevent this impl on stable. Let's just choose even stricter rules, since we shouldn't be implementing `Drop` on a foreign ADT ever.
Fixes#99575
rustc_metadata: dedupe strings to prevent multiple copies in rmeta/query cache blow file size
r? `@cjgillot`
Encodes strings in rmeta/query cache so duplicated ones will be encoded as offsets to first strings, reducing file size.
Revert "Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks, …
…r=oli-obk"
This reverts commit c703d11dcc, reversing
changes made to 64eb9ab869.
it didn't apply cleanly, so now it works the same for RPIT and for TAIT instead of just working for RPIT, but we should keep those in sync anyway. It also exposed a TAIT bug (see the feature gated test that now ICEs).
r? `@pnkfelix`
fixes#99536
