interpret/validity: debug-check ScalarPair layout information
This would have caught https://github.com/rust-lang/rust/issues/96158.
I ran the Miri test suite and it still passes.
r? `@oli-obk`
Report that opaque types are not allowed in impls even in the presence of other errors
fixes #96569
before this PR those useful errors were hidden because either `unused parameter` or `only traits defined in the current crate can be implemented for arbitrary types` got emitted first.
Add a new Rust attribute to support embedding debugger visualizers
Implemented [this RFC](https://github.com/rust-lang/rfcs/pull/3191) to add support for embedding debugger visualizers into a PDB.
Added a new attribute `#[debugger_visualizer]` and updated the `CrateMetadata` to store debugger visualizers for crate dependencies.
RFC: https://github.com/rust-lang/rfcs/pull/3191
do not suggest when trait_ref is some
Update compiler/rustc_resolve/src/late/diagnostics.rs
Co-authored-by: lcnr <rust@lcnr.de>
use helper struct
add a test for functions with some params
refactor debug log
Enable tracing for all queries
This allows you to log everything within a specific query, e.g.
```
env RUSTC_LOG=[mir_borrowck]
```
dumping all borrowck queries may be a bit verbose, so you can also restrict it to just an item of your choice:
```
env RUSTC_LOG=[mir_borrowck{key=\.\*name_of_item\.\*}]
```
the regex `.*` in the key name are because the key is a debug printed DefId, so you'd get all kinds of things like hashes in there. The tracing logs will show you the key, so you can restrict it further if you want.
Revert "Prefer projection candidates instead of param_env candidates for Sized predicates"
Fixes#93262Reopens#89352
This was a hack that seemed to have no negative side-effects at the time. Given that the latter has a workaround and likely less common than the former, it makes sense to revert this change.
r? `@compiler-errors`
Overhaul `MacArgs`
Motivation:
- Clarify some code that I found hard to understand.
- Eliminate one use of three places where `TokenKind::Interpolated` values are created.
r? `@petrochenkov`
The value in `MacArgs::Eq` is currently represented as a `Token`.
Because of `TokenKind::Interpolated`, `Token` can be either a token or
an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a
literal or macro call AST fragment, and then is later lowered to a
literal token. But this is very non-obvious. `Token` is a much more
general type than what is needed.
This commit restricts things, by introducing a new type `MacArgsEqKind`
that is either an AST expression (pre-lowering) or an AST literal
(post-lowering). The downside is that the code is a bit more verbose in
a few places. The benefit is that makes it much clearer what the
possibilities are (though also shorter in some other places). Also, it
removes one use of `TokenKind::Interpolated`, taking us a step closer to
removing that variant, which will let us make `Token` impl `Copy` and
remove many "handle Interpolated" code paths in the parser.
Things to note:
- Error messages have improved. Messages like this:
```
unexpected token: `"bug" + "found"`
```
now say "unexpected expression", which makes more sense. Although
arbitrary expressions can exist within tokens thanks to
`TokenKind::Interpolated`, that's not obvious to anyone who doesn't
know compiler internals.
- In `parse_mac_args_common`, we no longer need to collect tokens for
the value expression.
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.
