smir: merge identical Constant and ConstOperand types
The first commit renames the const operand visitor functions on regular MIR to match the type name, that was forgotten in the original rename.
The second commit changes stable MIR, fixing https://github.com/rust-lang/project-stable-mir/issues/71. Previously there were two different smir types for the MIR type `ConstOperand`, one used in `Operand` and one in `VarDebugInfoContents`.
Maybe we should have done this with https://github.com/rust-lang/rust/pull/125967, so there's only a single breaking change... but I saw that PR too late.
Fixes https://github.com/rust-lang/project-stable-mir/issues/71
Unify intrinsics body handling in StableMIR
rust-lang/rust#120675 introduced a new mechanism to declare intrinsics which will potentially replace the rust-intrinsic ABI.
The new mechanism introduces a placeholder body and mark the intrinsic with `#[rustc_intrinsic_must_be_overridden]`.
In practice, this means that a backend should not generate code for the placeholder, and shim the intrinsic.
The new annotation is an internal compiler implementation, and it doesn't need to be exposed to StableMIR users.
In this PR, we unify the interface for intrinsics marked with `rustc_intrinsic_must_be_overridden` and intrinsics that do not have a body.
Fixes https://github.com/rust-lang/project-stable-mir/issues/79
r? ``@oli-obk``
cc: ``@momvart``
We implement the trait only for definitions that should have a type.
It's possible that I missed a few definitions, but we can add them later
if needed.
rust-lang/rust#120675 introduced a new mechanism to declare intrinsics
which will potentially replace the rust-intrinsic ABI.
The new mechanism introduces a placeholder body and mark the intrinsic
with #[rustc_intrinsic_must_be_overridden].
In practice, this means that backends should not generate code for the
placeholder, and shim the intrinsic.
The new annotation is an internal compiler implementation,
and it doesn't need to be exposed to StableMIR users.
In this PR, intrinsics marked with `rustc_intrinsic_must_be_overridden`
are handled the same way as intrinsics that do not have a body.
Port `tests/run-make-fulldeps/hotplug_codegen_backend` to ui-fulldeps
This is the last remaining run-make-fulldeps test, which means I actually had to leave behind a dummy README file to prevent compiletest from complaining about a missing directory.
(Removing the run-make-fulldeps suite entirely is non-trivial, so I intend to do so in a separate PR after this one.)
---
I wasn't sure about adding a new kind of aux build just for this one test, so I also tried to just port this test from Makefile to [rmake](https://github.com/rust-lang/rust/issues/121876) instead.
But I found that I couldn't get rmake to fully work for a run-make-fulldeps test, which convinced me that getting rid of run-make-fulldeps is worthwhile.
r? `@jieyouxu`
Revert "Use the HIR instead of mir_keys for determining whether something will have a MIR body."
This reverts commit e5cba17b84.
turns out SMIR still needs it (https://github.com/model-checking/kani/issues/3218). I'll create a full plan and MCP for what I intended this to be a part of. Maybe my plan is nonsense anyway.
Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps
This test can run as an ordinary `tests/ui-fulldeps` test, with the help of some additional header variable substitutions to supply a sysroot and linker.
---
Unlike #125973, this test appears to be testing something vaguely useful and breakable, which is why I didn't just delete it.
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
[perf] Delay the construction of early lint diag structs
Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.
See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc671, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
* instead simply set the primary message inside the lint decorator functions
* it used to be this way before [#]101986 which introduced `msg` to prevent
good path delayed bugs (which no longer exist) from firing under certain
circumstances when lints were suppressed / silenced
* this is no longer necessary for various reasons I presume
* it shaves off complexity and makes further changes easier to implement
The starting point for this was identical comments on two different
fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
// FIXME: investigate making this a `Option<ErrorGuaranteed>`
recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed`
to `Recovered::Yes`. Then I ended up using `Recovered` instead of
`Option<ErrorGuaranteed>` for these two places and elsewhere, which
required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.
This makes things more consistent, because `Recovered` is used in more
places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible
to set `recovered` to `Recovered::Yes` without having emitted an error.
panic_str only exists for the migration to 2021 panic macros
The only caller is `expect_failed`, which is already a cold inline(never) function, so inlining into that function should be fine. (And indeed `panic_str` was `#[inline]` anyway.)
The existence of panic_str risks someone calling it when they should call `panic` instead, and I can't see a reason why this footgun should exist.
I also extended the comment in `panic` to explain why it needs a `'static` string -- I know I've wondered about this in the past and it took me quite a while to understand.
Add support to intrinsics fallback body
Before this fix, the call to `body()` would crash, since `has_body()` would return true, but we would try to retrieve the body of an intrinsic which is not allowed.
Instead, the `Instance::body()` function will now convert an Intrinsic into an Item before retrieving its body.
Note: I also changed how we monomorphize the instance body. Unfortunately, the call still ICE for some shims.
r? `@oli-obk`
Before this fix, the call to `body()` would crash, since `has_body()`
would return true, but we would try to retrieve the body of an intrinsic
which is not allowed.
Instead, the `Instance::body()` function will now convert an Intrinsic
into an Item before retrieving its body.
Add methods to create StableMIR constant
I've been experimenting with transforming the StableMIR to instrument the code with potential UB checks.
The modified body will only be used by our analysis tool, however, constants in StableMIR must be backed by rustc constants. Thus, I'm adding a few functions to build constants, such as building string and other primitives.
One question I have is whether we should create a global allocation instead for strings.
r? ``````@oli-obk``````
Add `intrinsic_name` to get plain intrinsic name
Add an `intrinsic_name` API to retrieve the plain intrinsic name. The plain name does not include type arguments (as `trimmed_name` does), which is more convenient to match with intrinsic symbols.
The internal diagnostic lint currently only allows one, because that was
all that occurred in practice. But rust-lang/rust-clippy/pull/12453
wants to introduce functions with more than one, and this limitation is
getting in the way.
Currently it only checks calls to functions marked with
`#[rustc_lint_diagnostics]`. This commit changes it to check calls to
any function with an `impl Into<{D,Subd}iagMessage>` parameter. This
greatly improves its coverage and doesn't rely on people remembering to
add `#[rustc_lint_diagnostics]`.
The commit also adds `#[allow(rustc::untranslatable_diagnostic)`]
attributes to places that need it that are caught by the improved lint.
These places that might be easy to convert to translatable diagnostics.
Finally, it also:
- Expands and corrects some comments.
- Does some minor formatting improvements.
- Adds missing `DecorateLint` cases to
`tests/ui-fulldeps/internal-lints/diagnostics.rs`.
