Note this does not produce a full stack all the way to the first call that specifies all monomorphic parameters, it's just shallowly mentioning the last call site.
Reduce duplication of RPO calculation of mir
Computing the RPO of mir is not a low-cost thing, but it is duplicate in many places. In particular the `iterate_to_fixpoint` method which is called multiple times when computing the data flow.
This PR reduces the number of times the RPO is recalculated as much as possible, which should save some compile time.
Fix duplicate directory separator in --remap-path-prefix.
The compiler will currently emit duplicate directory separators when `--remap-path-prefix` has an exact match of the working directory and it is invoked with a relative path to the main source file. For example
```bash
rustc src/main.rs -Cdebuginfo=2 --remap-path-prefix="$(pwd)=abc"
```
will produce the path `abc//src/main.rs` in debuginfo. This is because `some_path.join("")` will append a directory separator to `some_path` and then LLVM does not check if the working directory already ends a directory separator before concatenating it with the relative path.
RustWrapper: explicitly don't handle DXILPointerTyID
This new enum entry was introduced in https://reviews.llvm.org/D122268,
and if I'm reading correctly there's no case where we'd ever encounter
it in our uses of LLVM. To preserve the ability to compile this file
with -Werror -Wswitch we add an explicit case for this entry.
r? nikic
Enforce Copy bounds for repeat elements while considering lifetimes
fixes https://github.com/rust-lang/rust/issues/95477
this is a breaking change in order to fix a soundness bug.
Before this PR we only checked whether the repeat element type had an `impl Copy`, but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a`, then copying any type other than a `'static` one should have been rejected, but wasn't.
r? `@lcnr`
macros: subdiagnostic derive
Add a new macro, `#[derive(SessionSubdiagnostic)]`, which can be applied to structs that represent subdiagnostics, such as labels, notes, helps or suggestions.
`#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable, and this new derive should make it easier to port existing diagnostics to using these derives.
For example, consider the following subdiagnostic types...
```rust
#[derive(SessionSubdiagnostic)]
pub enum ExpectedIdentifierLabel<'tcx> {
#[label(slug = "parser-expected-identifier")]
WithoutFound {
#[primary_span]
span: Span,
}
#[label(slug = "parser-expected-identifier-found")]
WithFound {
#[primary_span]
span: Span,
found: String,
}
}
#[derive(SessionSubdiagnostic)]
#[suggestion_verbose(slug = "parser-raw-identifier")]
pub struct RawIdentifierSuggestion<'tcx> {
#[primary_span]
span: Span,
#[applicability]
applicability: Applicability,
ident: Ident,
}
```
...and the corresponding Fluent messages:
```fluent
parser-expected-identifier = expected identifier
parser-expected-identifier-found = expected identifier, found {$found}
parser-raw-identifier = escape `{$ident}` to use it as an identifier
```
These can be emitted using the new `subdiagnostic` function on `Diagnostic`...
```rust
diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span });
diag.subdiagnostic(RawIdentifierSuggestion { span, applicability, ident });
```
...or as part of a larger `#[derive(SessionDiagnostic)]`:
```rust
#[derive(SessionDiagnostic)]
#[error(slug = "parser-expected-identifier")]
pub struct ExpectedIdentifier {
#[primary_span]
span: Span,
token_descr: String,
#[subdiagnostic]
label: ExpectedIdentifierLabel,
#[subdiagnostic]
raw_identifier_suggestion: Option<RawIdentifierSuggestion>,
}
```
```rust
sess.emit_err(ExpectedIdentifier { ... });
```
r? `@oli-obk`
cc `@pvdrz`
Revert diagnostic duplication and accidental stabilization
fixes#96460
this is an accidental stabilization that we should put into the beta. I believe it is low-risk, because it was literally what we had before #94081
The effect on tests is massive, but mostly deduplication of diagnostics and some minor span changes.
Update data layout string for wasm64-unknown-unknown
Looks like this changed in a recent LLVM update but wasm64 isn't built
on CI so it wasn't caught until now.
Closes#96463
Add `#[subdiagnostic]` field attribute to the diagnostic derive which
is applied to fields that have types which use the subdiagnostic derive.
Signed-off-by: David Wood <david.wood@huawei.com>
In the initial implementation of the `SessionSubdiagnostic`, the
`Applicability` of a suggestion can be set both as a field and as part
of the attribute, this commit adds the same support to the original
`SessionDiagnostic` derive.
Signed-off-by: David Wood <david.wood@huawei.com>
`SetOnce` trait was introduced in the subdiagnostic derive to simplify
the code a little bit, re-use it in the diagnostic derive too.
Signed-off-by: David Wood <david.wood@huawei.com>
Remove some duplicated code between both diagnostic derives by
introducing helper functions for reporting an error in case of a invalid
attribute.
Signed-off-by: David Wood <david.wood@huawei.com>
Split `SessionDiagnostic` and `SessionSubdiagnostic` derives and the
various helper functions into multiple modules.
Signed-off-by: David Wood <david.wood@huawei.com>
Add a new derive, `#[derive(SessionSubdiagnostic)]`, which enables
deriving structs for labels, notes, helps and suggestions.
Signed-off-by: David Wood <david.wood@huawei.com>
Change `span_suggestion` (and variants) to take `impl ToString` rather
than `String` for the suggested code, as this simplifies the
requirements on the diagnostic derive.
Signed-off-by: David Wood <david.wood@huawei.com>
rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`
Compiler cannot reuse `proc_macro::Delimiter` directly due to extra impls, but can at least use the same naming.
After this PR the only difference between these two enums is that `proc_macro::Delimiter::None` is turned into `token::Delimiter::Invisible`.
It's my mistake that the invisible delimiter is called `None` on stable, during the stabilization I audited the naming and wrote the docs, but missed the fact that the `None` naming gives a wrong and confusing impression about what this thing is.
cc https://github.com/rust-lang/rust/pull/96421
r? ``@nnethercote``
This new enum entry was introduced in https://reviews.llvm.org/D122268,
and if I'm reading correctly there's no case where we'd ever encounter
it in our uses of LLVM. To preserve the ability to compile this file
with -Werror -Wswitch we add an explicit case for this entry.
Implement Valtree to ConstValue conversion
Once we start to use `ValTree`s in the type system we will need to be able to convert them into `ConstValue` instances, which we want to continue to use after MIR construction.
r? `@oli-obk`
cc `@RalfJung`
Make sure `-Dunused-crate-dependencies --json unused-externs` makes rustc exit with error status
This PR:
- fixes compiletest to understand unused extern notifications
- adds tests for `--json unused-externs`
- makes sure that deny-level unused externs notifications are treated as compile errors
- refactors the `emit_unused_externs` callstack to plumb through the level as an enum as a string, and adds `Level::is_error`
Update: adds `--json unused-externs-silent` with the original behaviour since Cargo needs it. Should address `@est31's` concerns.
Fixes: https://github.com/rust-lang/rust/issues/96068
Add missing `target_feature` to the list of well known cfg names
This PR adds the missing `target_feature` cfg name to the list of well known cfg names.
It was notice missing in https://github.com/rust-lang/rust/issues/96472 thanks to `@bjorn3,` the reason being that `--check-cfg=names()` automatically inherit the names passed by `--cfg` (or internal to `rustc`) and is seems that the vast majority of targets have at least one target feature leading to `target_feature` being a well known name in most target but it should always be a well known name so this PR add it unconditionally to list.
r? `@petrochenkov`
not need `Option` for `dbg_scope`
This PR fixes a few FIXME about not using `Option` in `dbg_scope` field of `DebugScope`, during `create_function_debug_context` func in codegen parts.
Added a `BitSet<SourceScope>` parameter to `make_mir_scope` to indicate whether the `DebugScope` has been instantiated.
cc ````@eddyb````
Less `NoDelim`
Currently there are several places where `NoDelim` (which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The name `NoDelim` is a bit misleading, and may be a cause.
This PR changes these places, e.g. by changing a `DelimToken` to `Option<DelimToken>` and then using `None` to mean "no delimiter". As a result, the *only* place where `NoDelim` values are now produced is within:
- `Delimiter::to_internal()`, when converting from `Delimiter::None`.
- `FlattenNonterminals::process_token()`, when converting `TokenKind::Interpolated`.
r? ````@petrochenkov````
make `fn() -> _ { .. }` suggestion MachineApplicable
This might not be valid, but it would be nice to promote this to `MachineApplicable` so people can use rustfix here.
Also de65fcf009d07019689cfad7f327667e390a325d is to [restore the suggestion for `issue-77179.rs`](de65fcf009 (diff-12e43fb5d6d12ec7cb5c6b48204a18d113cf5de0e12eb71a358b639bd9aadaf0R8)). (though in this case, the code in that issue still doesn't compile, so it's not marked with rustfix).
Perform lifetime resolution on the AST for lowering
Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes, and once in the resolve_lifetimes query. However, due to the global nature of lifetime resolution and how it interferes with hygiene, it is better suited on the AST.
This PR implements a first draft of lifetime resolution on the AST. For now, we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported, and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST.
We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics`, which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes.
r? `@petrochenkov`
