Update `ProjectionElem::Downcast` documentation
`ProjectionElem:::Downcast` is used when downcasting to a variant of
an enum or a generator, regardless of the number of variants.
Quick fix for #96223.
This PR is a quick fix regarding #96223.
As mentioned in the issue, others modification could be added to not elide types with bound vars from suggestions.
Special thanks to ``@jackh726`` for mentoring and ``@Manishearth`` for minimal test case.
r? ``@jackh726``
When suggesting to import an item, also suggest changing the path if appropriate
When we don't find an item we search all of them for an appropriate
import and suggest `use`ing it. This is sometimes done for expressions
that have paths with more than one segment. We now also suggest changing
that path to work with the `use`.
Fix#95413
The comment on this function explains that it's a specialized version of
`maybe_whole_expr`. But `maybe_whole_expr` doesn't do anything with
`NtIdent`, so `is_whole_expr` also doesn't need to.
Cleanup `DebuggerVisualizerFile` type and other minor cleanup of queries.
Merge the queries for debugger visualizers into a single query.
Revert move of `resolve_path` to `rustc_builtin_macros`. Update dependencies in Cargo.toml for `rustc_passes`.
Respond to PR comments. Load visualizer files into opaque bytes `Vec<u8>`. Debugger visualizers for dynamically linked crates should not be embedded in the current crate.
Update the unstable book with the new feature. Add the tracking issue for the debugger_visualizer feature.
Respond to PR comments and minor cleanups.
Use reverse postorder in `non_ssa_locals`
The reverse postorder, unlike preorder, is now cached inside the MIR
body. Code generation uses reverse postorder anyway, so it might be
a small perf improvement to use it here as well.
Mitigate impact of subtle invalid call suggestion logic
There's some subtle interaction between inferred expressions being
passed as an argument to fn calls with fewer than expected arguments. To
avoid the ICE, I'm changing indexing operations with `.get(idx)`, but
the underlying logic still needs to be audited as it was written with
the assumption that `final_arg_types` and `provided_args` have the right
length.
Address #96638.
Update `RValue::Discriminant` documentation
`RValue::Discriminant` returns zero for types without discriminant.
This guarantee is already documented for `discriminant_value`
intrinsics which is implemented in terms of `RValue::Discriminant`.
Use source callsite in check_argument_types suggestion
This makes the "remove extra arguement" suggestion valid when the function argument is a macro.
Additionally, this may fix#96225, but the only way I can reproduce that issue is using the playground, so we will need to wait until after this is merged to ensure it's fixed.
Refactor the WriteBackendMethods and ExtraBackendMethods traits
The new interface is slightly less confusing and is easier to implement for non-LLVM backends.
When we don't find an item we search all of them for an appropriate
import and suggest `use`ing it. This is sometimes done for expressions
that have paths with more than one segment. We now also suggest changing
that path to work with the `use`.
Fix#95413
There's some subtle interaction between inferred expressions being
passed as an argument to fn calls with fewer than expected arguments. To
avoid the ICE, I'm changing indexing operations with `.get(idx)`, but
the underlying logic still needs to be audited as it was written with
the assumption that `final_arg_types` and `provided_args` have the right
length.
Address 96638.
Fix -Zdump-mir-dataflow by implementing DebugWithContext for ChunkedBitSet
`DebugWithContext` is used to format changes to dataflow state along with MIR
in graphviz dot files. In the case of `ChunkedBitSet` it was left unimplemented,
so attempts to use `-Zdump-mir-dataflow -Zdump-mir=all` resulted in an ICE:
> thread 'rustc' panicked at 'not implemented: implement when/if needed',
Provide the missing implementation.
r? `@nnethercote`
rustc: Panic by default in `DefIdTree::parent`
Only crate root def-ids don't have a parent, and in majority of cases the argument of `DefIdTree::parent` cannot be a crate root.
So we now panic by default in `parent` and introduce a new non-panicing function `opt_parent` for cases where the argument can be a crate root.
Same applies to `local_parent`/`opt_local_parent`.
Only crate root def-ids don't have a parent, and in majority of cases the argument of `DefIdTree::parent` cannot be a crate root.
So we now panic by default in `parent` and introduce a new non-panicing function `opt_parent` for cases where the argument can be a crate root.
Same applies to `local_parent`/`opt_local_parent`.
rustdoc: Resolve doc links referring to `macro_rules` items
cc https://github.com/rust-lang/rust/issues/81633
UPD: the fallback to considering *all* `macro_rules` in the crate for unresolved names is not removed in this PR, it will be removed separately and will be run through crater.
The reverse postorder, unlike preorder, is now cached inside the MIR
body. Code generation uses reverse postorder anyway, so it might be
a small perf improvement to use it here as well.
Also report the call site of PME errors locally.
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.
previous work: https://github.com/rust-lang/rust/pull/85633
tracking issue: https://github.com/rust-lang/rust/issues/85155
r? `@lqd`
I figured we could get some improvement for traces in local crates without going into the backtrace hell you landed in last time
`RValue::Discriminant` returns zero for types without discriminant.
This guarantee is already documented for `discriminant_value`
intrinsics which is implemented in terms of `RValue::Discriminant`.
Using an obviously-placeholder syntax. An RFC would still be needed before this could have any chance at stabilization, and it might be removed at any point.
But I'd really like to have it in nightly at least to ensure it works well with try_trait_v2, especially as we refactor the traits.
Erase type params when suggesting fully qualified path
When suggesting the use of a fully qualified path for a method call that
is ambiguous because it has multiple candidates, erase type params in
the resulting code, as they would result in an error when applied. We
replace them with `_` in the output to rely on inference. There might be
cases where this still produces slighlty incomplete suggestions, but it
otherwise produces many more errors in relatively common cases.
Fix#96292
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.
Enforce static lifetimes in consts during late resolution
This PR moves the handling of implicitly and explicitly static lifetimes in constants from HIR to the AST.
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
The two paths are equivalent -- they both end up calling `visit_expr()`.
I have kept the more restrictive path, the one that requires that
`token` be an expression nonterminal. (The next commit will simplify this
function further.)
The `token` is always an interpolated non-terminal expression, and
always a literal in valid code. This commit simplifies the processing
accordingly, by directly extracting and using the literal.
This commit rearranges the `match`. The new code avoids testing for
`MacArgs::Eq` twice, at the cost of repeating the `self.print_path()`
call. I think this is worthwhile because it puts the `match` in a more
standard and readable form.
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`
Since Cargo wants to do its own fatal error handling for unused
dependencies, add the option `--json unused-externs-silent` which
has the original behaviour of not indicating non-zero exit status for
`deny`/`forbid`-level unused dependencies.
Rollup of 6 pull requests
Successful merges:
- #92569 (Improve Error Messaging for Unconstructed Structs and Enum Variants in Generic Contexts)
- #96370 (Cleanup `report_method_error` a bit)
- #96383 (Fix erased region escaping into wfcheck due to #95395)
- #96385 (Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL)
- #96410 (rustdoc: do not write `{{root}}` in `pub use ::foo` docs)
- #96430 (Fix handling of `!` in rustdoc search)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL
This is done by replacing the duplicated (and very partial) implementation from borrowck with one inspsired from `NiceRegionError::try_report_static_impl_trait` and by re-using `suggest_new_region_bound`.
Fixes#96277
r? ```@jackh726```
Fix erased region escaping into wfcheck due to #95395
We can just use `liberate_late_bound_regions` instead of `erase_late_bound_regions`... This gives us `ReEarlyBound` instead of `ReErased`, the former being something typeck actually knows how to deal with...
Fixes#96381
Side-note: We only actually get far enough in the compiler pipeline to cause this ICE when we're invoking rustdoc. We actually abort rustc right before wfcheck because of the error that we emit (having `_` in the type signature). Why does rustdoc keep going even though we raise an error?
Cleanup `report_method_error` a bit
1. Remove an unnecessary indentation level
2. Split out a couple of large functions from this humongo function body
Fix incremental perf regression unsafety checking
Perf regression introduced in #96294
We will simply avoid emitting the name of the unsafe function in MIR unsafeck, since we're moving to THIR unsafeck anyway.
The code currently ignores the actual delimiter on the RHS and fakes up
a `NoDelim`/`DelimSpan::dummy()` one. This commit changes it to use the
actual delimiter.
The commit also reorders the fields for the `Delimited` variant to match
the `Sequence` variant.
Correct documentation for `Rvalue::ShallowInitBox`
As a part of the big MIR docs PR, I had added a comment indicating that `Rvalue::ShallowInitBox` is disallowed after drop elaboration, but this is not true (no idea why I thought it was). Codegen has support for it, and trying to enforce this rule in the validator causes compiling core to ICE on the very first `box` statement.
That being said, this `Rvalue` probably *should* be banned after drop elaboration - it doesn't seem like it's still useful for much. However, I do not have time right now to actually go investigate how difficult a change that is to make, so in the meantime fixing the docs to reflect the current situation seems like the right step.
r? rust-lang/mir-opt
simplify `describe_field` func in borrowck's diagnostics part
This PR simplify the `describe_field` func in borrowck's diagnostics part, besides fix the FIXME in it.
Suggest calling method on nested field when struct is missing method
Similar to the suggestion to change `x.field` to `x.nested.field`, implement a similar suggestion for when `x.method()` should be replaced with `x.nested.method()`.
Fix codegen bug in "ptx-kernel" abi related to arg passing
I found a codegen bug in the nvptx abi related to that args are passed as ptrs ([see comment](https://github.com/rust-lang/rust/issues/38788#issuecomment-1048999928)), this is not as specified in the [ptx-interoperability doc](https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/) or how C/C++ does it. It will also almost always fail in practice since device/host uses different memory spaces for most hardware.
This PR fixes the bug and add tests for passing structs to ptx kernels.
I observed that all nvptx assembly tests had been marked as [ignore a long time ago](https://github.com/rust-lang/rust/pull/59752#issuecomment-501713428). I'm not sure if the new one should be marked as ignore, it passed on my computer but it might fail if ptx-linker is missing on the server? I guess this is outside scope for this PR and should be looked at in a different issue/PR.
I only fixed the nvptx64-nvidia-cuda target and not the potential code paths for the non-existing 32bit target. Even though 32bit nvptx is not a supported target there are still some code under the hood supporting codegen for 32 bit ptx. I was advised to create an MCP to find out if this code should be removed or updated.
Perhaps ``@RDambrosio016`` would have interest in taking a quick look at this.
Fix incorrect suggestion for trait bounds involving binary operators
This PR fixes#93927, #92347, #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path.
The downside is that this fix causes some suggestions to not include an `Output=` type, reducing their usefulness.
Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.
Rollup of 6 pull requests
Successful merges:
- #90312 (Fix some confusing wording and improve slice-search-related docs)
- #96149 (Remove unused macro rules)
- #96279 (rustdoc: Remove .woff font files)
- #96355 (Better handle too many `#` recovery in raw str)
- #96379 (delay bug when adjusting `NeverToAny` twice during diagnostic code)
- #96384 (do not consider two extern types to be similar)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
delay bug when adjusting `NeverToAny` twice during diagnostic code
Addresses Issue 96335 (https://github.com/rust-lang/rust/issues/96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`.
Fixes#96335
Better handle too many `#` recovery in raw str
Point at all the unnecessary trailing `#`.
Better handle interaction with outer attributes when `;` is missing.
Fix#95030.
Display function path in unsafety violations - E0133
adds `DefId` to `UnsafetyViolationDetails`
this enables consumers to access the function definition that was reported to be unsafe and also changes the output for some E0133 diagnostics
Generate synthetic object file to ensure all exported and used symbols participate in the linking
Fix#50007 and #47384
This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354, allowing all exported and used symbols to be linked while still allowing them to be GCed.
Related #93791, #95363
r? `@petrochenkov`
cc `@carbotaniuman`
Add `BoundKind` in `visit_param_bounds` to check questions in bounds
From the FIXME in the impl of `AstValidator`. Better bound checks by adding `BoundCtxt` type parameter to `visit_param_bound`
cc `@ecstatic-morse`
