b583ede652
Stabilize `#![feature(target_feature_11)]`
## Stabilization report
### Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.
Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits.
However, calling them from other `#[target_feature]` functions with a superset of features is safe.
```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}
fn foo() {
// Calling `avx2` here is unsafe, as we must ensure
// that AVX is available first.
unsafe {
avx2();
}
}
#[target_feature(enable = "avx2")]
fn bar() {
// Calling `avx2` here is safe.
avx2();
}
```
### Test cases
Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](b67ba9ba20/src/test/ui/rfcs/rfc-2396-target_feature-11/).
### Edge cases
- https://github.com/rust-lang/rust/issues/73631
Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.
```rust
#[target_feature(enable = "avx2")]
fn qux() {
let my_closure = || avx2(); // this call to `avx2` is safe
let f: fn() = my_closure;
}
```
This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives.
### Documentation
- Reference: https://github.com/rust-lang/reference/pull/1181
---
cc tracking issue #69098
r? `@ghost`
This folder contains tests for MIR optimizations.
The mir-opt test format emits MIR to extra files that you can automatically update by specifying
--bless on the command line (just like ui tests updating .stderr files).
--blessable test format
By default 32 bit and 64 bit targets use the same dump files, which can be problematic in the presence of pointers in constants or other bit width dependent things. In that case you can add
// EMIT_MIR_FOR_EACH_BIT_WIDTH
to your test, causing separate files to be generated for 32bit and 64bit systems.
Unit testing
If you are only testing the behavior of a particular mir-opt pass on some specific input (as is usually the case), you should add
// unit-test: PassName
to the top of the file. This makes sure that other passes don't run which means you'll get the input you expected and your test won't break when other code changes.
Emit a diff of the mir for a specific optimization
This is what you want most often when you want to see how an optimization changes the MIR.
// EMIT_MIR $file_name_of_some_mir_dump.diff
Emit mir after a specific optimization
Use this if you are just interested in the final state after an optimization.
// EMIT_MIR $file_name_of_some_mir_dump.after.mir
Emit mir before a specific optimization
This exists mainly for completeness and is rarely useful.
// EMIT_MIR $file_name_of_some_mir_dump.before.mir