`WrappingRange::is_full` computation assumed that to be full the range
couldn't wrap, which is not necessarily true.
For example, a range of 1..=0 is a valid representation of a full
wrapping range.
`CompilerError` has `CompilationFailed` and `ICE` variants, which seems
reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`,
it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses
`ICE`. This is sometimes right, because ICEs do cause `FatalError`
panics, but sometimes wrong, because certain compiler errors also
cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just
catches the `FatalError` with `catch_with_exit_code` in `main`.)
In other words, certain non-ICE compilation failures get miscategorized
as ICEs. It's not possible to reliably distinguish the two cases, so
this commit merges them. It also renames the combined variant as just
`Failed`, to better match the existing `Interrupted` and `Skipped`
variants.
Here is an example of a non-ICE failure that causes a `FatalError`
panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
#![recursion_limit="4"]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
//~^ERROR recursion limit reached while expanding
fn main() {{}}
```
Add more information to `visit_projection_elem`
Without the starting place, it's hard to retrieve any useful information from visiting a projection.
Note: I still need to add a test.
Add method to get instance instantiation arguments
Add a method to get the instance instantiation arguments, and include that information in the instance debug.
Add function ABI and type layout to StableMIR
This change introduces a new module to StableMIR named `abi` with information from `rustc_target::abi` and `rustc_abi`, that allow users to retrieve more low level information required to perform bit-precise analysis.
The layout of a type can be retrieved via `Ty::layout`, and the instance ABI can be retrieved via `Instance::fn_abi()`.
To properly handle errors while retrieve layout information, we had to implement a few layout related traits.
r? ```@compiler-errors```
This change introduces a new module to StableMIR named `abi` with
information from `rustc_target::abi` and `rustc_abi`, that allow users
to retrieve more low level information required to perform
bit-precise analysis.
The layout of a type can be retrieved via `Ty::layout`, and the instance
ABI can be retrieved via `Instance::fn_abi()`.
To properly handle errors while retrieve layout information, we had
to implement a few layout related traits.
Erase late bound regions from `Instance::fn_sig()` and add a few more details to StableMIR APIs
The Instance `fn_sig()` still included a late bound regions which needed a new compiler function in order to be erased. I've also bundled the following small fixes in this PR, let me know if you want me to isolate any of them.
- Add missing `CoroutineKind::AsyncGen`.
- Add optional spread argument to function body which is needed to properly analyze compiler shims.
- Add a utility method to iterate over all locals together with their declaration.
- Add a method to get the description of `AssertMessage`*.
* For the last one, we could consider eventually calling the internal `AssertKind::description()` to avoid code duplication. However, we still don't have ways to convert `AssertMessage`, `Operand`, `Place` and others, in order to use that. The other downside of using the internal method is that it will panic for some of the variants.
r ? `@ouz-a`
- Remove `fn_sig()` from Instance.
- Change return value of `AssertMessage::description` to `Cow<>`.
- Add assert to instance `ty()`.
- Generalize uint / int type creation.
Fix BinOp `ty()` assertion and `fn_sig()` for closures
`BinOp::ty()` was asserting that the argument types were primitives. However, the primitive check doesn't include pointers, which can be used in a `BinaryOperation`. Thus extend the arguments to include them.
Since I had to add methods to check for pointers in TyKind, I just went ahead and added a bunch more utility checks that can be handy for our users and fixed the `fn_sig()` method to also include closures.
`@compiler-errors` just wanted to confirm that today no `BinaryOperation` accept SIMD types. Is that correct?
r? `@compiler-errors`
detects redundant imports that can be eliminated.
for #117772 :
In order to facilitate review and modification, split the checking code and
removing redundant imports code into two PR.
The instance evaluation is needed to handle intrinsics such as
`type_id` and `type_name`.
Since we now use Allocation to represent all evaluated constants,
provide a few methods to help process the data inside an allocation.
Add method to get type of an Rvalue in StableMIR
Provide a method to StableMIR users to retrieve the type of an Rvalue operation. There were two possible implementation:
1. Create the logic inside stable_mir to process the type according to the Rvalue semantics, which duplicates the logic of `rustc_middle::mir::Rvalue::ty()`.
2. Implement the Rvalue translation from StableMIR back to internal representation, invoke the `rustc_middle::mir::Rvalue::ty()`, and translate the return value to StableMIR.
I chose the first one for now since the duplication was fairly small, and the option 2 would require way more work to translate everything back to rustc internal representation. If we eventually add those translations, we could easily swap to the option 2.
```@compiler-errors``` / ```@ouz-a``` Please let me know if you have any strong opinion here.
r? ```@compiler-errors```
