interpret: go back to regular string interpolation for error messages
Using the translatable diagnostic infrastructure adds a whole lot of boilerplate which isn't actually useful for const-eval errors, so let's get rid of it. This effectively reverts https://github.com/rust-lang/rust/pull/111677. That PR effectively added 1000 lines and this PR only removes around 600 -- the difference is caused by (a) keeping some of the types around for validation, where we can use them to share error strings and to trigger the extra help for pointer byte shenanigans during CTFE, and (b) this not being a full revert of rust-lang/rust#111677; I am not touching diagnostics outside the interpreter such as all the const-checking code which also got converted to fluent in the same PR.
The last commit does something similar for `LayoutError`, which also helps deduplicate a bunch of error strings. I can make that into a separate PR if you prefer.
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/113117
Fixes https://github.com/rust-lang/rust/issues/116764
Fixes https://github.com/rust-lang/rust/issues/112618
Move `Spanned`.
It's defined in `rustc_span::source_map` which doesn't make any sense because it has nothing to do with source maps. This commit moves it to the crate root, a more sensible spot for something this basic.
r? @JonathanBrouwer
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
Overhaul `ensure_ok`
The interaction of `ensure_ok` and the `return_result_from_ensure_ok` query modifier is weird and hacky. This PR cleans it up. Details in the individual commits.
r? @Zalathar
`ensure_ok` provides a special, more efficient way of calling a query
when its return value isn't needed. But there is a complication: if the
query is marked with the `return_result_from_ensure_ok` modifier, then
it will return `Result<(), ErrorGuaranteed`. This is clunky and feels
tacked on. It's annoying to have to add a modifier to a query to declare
information present in its return type, and it's confusing that queries
called via `ensure_ok` have different return types depending on the
modifier.
This commit:
- Eliminates the `return_result_from_ensure_ok` modifier. The proc macro
now looks at the return type and detects if it matches `Result<_,
ErrorGuarantee>`. If so, it adds the modifier
`returns_error_guaranteed`. (Aside: We need better terminology to
distinguish modifiers written by the user in a `query` declaration
(e.g. `cycle_delayed_bug`) from modifiers added by the proc macro
(e.g. `cycle_error_handling`.))
- Introduces `ensure_result`, which replaces the use of `ensure_ok` for
queries that return `Result<_, ErrorGuarantee>`. As a result,
`ensure_ok` can now only be used for the "ignore the return value"
case.
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
Don't allow subdiagnostic to use variables from their parent
Tangentially related to https://github.com/rust-lang/rust/issues/151366
This is PR 1/2 for structured diagnostics, will do the unstructured ones next. After the second PR I will be able to remove some code that should compensate for this PR being positive.
Regardless of this PR having a positive diff, I feel that subdiagnostics being able to use variables from their parent is very confusing, so this is for the better,.
r? @jdonszelmann
Rename `rustc::pass_by_value` lint as `rustc::disallowed_pass_by_ref`.
The name `pass_by_value` is completely wrong. The lint actually checks for the use of pass by reference for types marked with `rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_` part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
r? @Urgau
The name `pass_by_value` is completely wrong. The lint actually checks
for the use of pass by reference for types marked with
`rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_`
part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy
lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
GVN: consider constants of primitive types as deterministic
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149366)*
GVN separates MIR constants into deterministic and non-deterministic constants. Deterministic constants are defined here as: gives the exact same value each time it is evaluated.
This was mainly useful because of `ConstValue::Slice` that generated an extra `AllocId` each time it appeared in the MIR. That variant has been removed. This is still useful for valtrees that hold references, which generate a fresh `AllocId` for each evaluation.
This PR proposes to consider all constants of primitive type to be deterministic. If a constant of primitive type passes validation, then it does not contain provenance, so we have no risk of having a reference becoming different `AllocId`s. In particular, valtrees only are leaves.
r? @ghost for perf
Remove redundant call to `check_codegen_attributes_extra` in Inliner
Inside `try_inlining`, `check_codegen_attributes` is called first. This function internally invokes `check_codegen_attributes_extra`.
However, immediately after that returns, `try_inlining` calls `check_codegen_attributes_extra` again.
First call:
https://github.com/rust-lang/rust/blob/7ec34defe9e62a1a6946d3e700b5903d8dc89ece/compiler/rustc_mir_transform/src/inline.rs#L800-L814
Second call:
https://github.com/rust-lang/rust/blob/7ec34defe9e62a1a6946d3e700b5903d8dc89ece/compiler/rustc_mir_transform/src/inline.rs#L598-L612
```rust
// Inside try_inlining:
check_codegen_attributes(inliner, callsite, callee_attrs)?; // Internally calls `check_codegen_attributes_extra`
inliner.check_codegen_attributes_extra(callee_attrs)?; // Called again here
```
In `try_inlining`, inliner is held as a shared reference (`&I`). Since `check_codegen_attributes_extra` takes `&self` and does not rely on interior mutability or external state, there does not seem to be any state change between the two calls.
Therefore, the second call appears to be redundant.
Currently, `check_codegen_attributes` is only called from `try_inlining`, and `check_codegen_attributes_extra` appears to be called only from these two locations. It seems reasonable for the `check_codegen_attributes` wrapper to handle the hook automatically.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
Not linting irrefutable_let_patterns on let chains
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146832)*
# Description
this PR makes the lint `irrefutable_let_patterns` not check for `let chains`,
only check for single `if let`, `while let`, and `if let guard`.
# Motivation
Since `let chains` were stabilized, the following code has become common:
```rust
fn max() -> usize { 42 }
fn main() {
if let mx = max() && mx < usize::MAX { /* */ }
}
```
This code naturally expresses "please call that function and then do something if the return value satisfies a condition".
Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent.
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src/main.rs:7:8
|
7 | if let mx = max() && mx < usize::MAX {
| ^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
```
Another common case is progressively destructuring a struct with enum fields, or an enum with struct variants:
```rust
struct NameOfOuterStruct {
middle: NameOfMiddleEnum,
other: (),
}
enum NameOfMiddleEnum {
Inner(NameOfInnerStruct),
Other(()),
}
struct NameOfInnerStruct {
id: u32,
}
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct { middle, .. } = outer
&& let NameOfMiddleEnum::Inner(inner) = middle
&& let NameOfInnerStruct { id } = inner
{
/* */
}
}
```
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src\main.rs:17:8
|
17 | if let NameOfOuterStruct { middle, .. } = outer
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
warning: trailing irrefutable pattern in let chain
--> src\main.rs:19:12
|
19 | && let NameOfInnerStruct { id } = inner
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it into the body
```
To avoid the warning, the readability would be much worse:
```rust
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct {
middle: NameOfMiddleEnum::Inner(NameOfInnerStruct { id }),
..
} = outer
{
/* */
}
}
```
# related issue
* rust-lang/rust#139369
# possible questions
1. Moving the irrefutable pattern at the head of the chain out of it would cause a variable that was intended to be temporary to remain in scope, so we remove it.
However, should we keep the check for moving the irrefutable pattern at the tail into the body?
2. Should we still lint `entire chain is made up of irrefutable let`?
---
This is my first time contributing non-documentation code to Rust. If there are any irregularities, please feel free to point them out.
: )
Ralf Jung