smoke-test for async fn with mir-opt-level=0
MIR opt levels heavily influence which MIR transformations run, and we barely test non-default opt levels. I am particularly worried about `async fn` lowering and how it might (not) work when the set of preceding MIR passes changes -- see https://github.com/rust-lang/rust/pull/70073.
This adds some basic smoke testing, where at least a few `async fn` `run-pass` test are ensured to also work with mir-opt-level=0.
Remove support for self-opening
This was only used for linkage test cases, which is already covered by
the [run-make-fulldeps/symbol-visibility test](https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/symbol-visibility/Makefile) -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
This fixes#10379 and resolves#10356 by removing the test case (and underlying support in the compiler). AFAICT, the better way to test visibility is via nm, like the symbol visibility test. It seems like that's sufficient; I suspect that given that we don't use this we should just drop it (android is tier 2 anyway). But happy to hear otherwise.
Add a function to turn Box<T> into Box<[T]>
Hi,
I think this is very useful, as currently it's not possible in safe rust to do this without re-allocating.
an alternative implementation of the same function can be:
```rust
pub fn into_boxed_slice<T>(boxed: Box<T>) -> Box<[T]> {
unsafe {
let slice = slice::from_raw_parts_mut(Box::into_raw(boxed), 1);
Box::from_raw(slice)
}
}
```
The only thing that makes me a little uncomfortable is this line :
> The alignment of array types is greater or equal to the alignment of its element type
from https://rust-lang.github.io/unsafe-code-guidelines/layout/arrays-and-slices.html
But then I see:
> The alignment of &T, &mut T, *const T and *mut T are the same, and are at least the word size.
> The alignment of &[T] is the word size.
from https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html#representation
So I do believe this is valid(FWIW it also passes in miri https://play.rust-lang.org/?gist=c002b99364ee6b29862aeb3565a91c19)
The referenced `sanitizer-address/Makefile` no longer exists, so perhaps these options are no longer necessary as well.
Even if they are still necessary, they should use `-C relocation-model=static` instead.
[breaking change] Disallow statics initializing themselves
fixes#71078
Self-initialization is unsound because it breaks privacy assumptions that unsafe code can make. In
```rust
pub mod foo {
#[derive(Debug, Copy, Clone)]
pub struct Foo {
x: (),
}
}
pub static FOO: foo::Foo = FOO;
```
unsafe could could expect that ony functions inside the `foo` module were able to create a value of type `Foo`.
Add all remaining `DefKind`s.
r? @eddyb or @Centril
~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~
~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
This was only used for linkage test cases, which is already covered by
the run-make-fulldeps/symbol-visibility test -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
Quick and dirty fix of the unused_braces lint
cc @lcnr
Adresses #70814
This at least prevents lint output, if no span is available. Even though this also prevents the `unused_parens` lint from emitting, when the `DUMMY_SP` is used there, but I think that should be ok, since error messages without a span are quite useless anyway.
Clippy CI is currently blocked on this bug. If this quick and dirty fix should be rejected, I could try to work around this in Clippy.
r? @shepmaster
Fix span of while (let) expressions after lowering
Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy.
While `if`, `try`, `for` and `await` expressions get the span of the original expression when desugared, `while` loops got the span of the scrutinee, which lead to weird code, when building the suggestion, that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108
I'm wondering, if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly, a new span with `self.mark_span_with_reason` should be used, like it is done with `for` loops.
There was some fallout, but I think that is acceptable. If not, I need some help to find out where this can be fixed.
Only run dataflow for const qualification if type-based check would fail
This is the optimization discussed in https://github.com/rust-lang/rust/issues/49146#issuecomment-614012476. We wait for `Qualif::in_any_value_of_ty` to return `true` before running dataflow. For bodies that deal mostly with primitive types, this will avoid running dataflow at all during const qualification.
This also removes the `BitSet` used to cache `in_any_value_of_ty` for each local, which was only necessary for an old version of #64470 that also handled promotability.
Rollup of 5 pull requests
Successful merges:
- #71235 (Tweak `'static` suggestion code)
- #71318 (miri-unleash tests: ensure they fire even with 'allow(const_err)')
- #71428 (Let compiletest recognize gdb 10.x)
- #71475 (Miri Frame: use mir::Location to represent position in function)
- #71476 (more compact way to adjust test sizes for Miri)
Failed merges:
r? @ghost
Add leading 0x to offset in Debug fmt of Pointer
Currently the `Debug` format for `Pointer` prints its offset in hexadecimal, for example, `alloc38657819+e2` or `alloc35122748+64`. This PR adds a leading `0x` to the offset, in order to make it apparent that it is indeed a hexadecimal number. This came up during discussion of rust-lang/miri#1354. r? @RalfJung
Stabilize UNICODE_VERSION (feature unicode_version)
Tracking issue: #49726
r? @sfackler
#71020 changed the definition of `UNICODE_VERSION` just yesterday from a struct to a tuple. Maybe you want to wait some more before stabilizing this constant, on the other hand this is a very small and simple addition.
CC @behnam @SimonSapin @Serentty
Make the `structural_match` error diagnostic for const generics clearer
The previous diagnostic caused confusion (https://github.com/rust-lang/rust/issues/70790), so this changes the message to be closer to the message for using non-`structural_match` constants in patterns, explicitly mentioning `#[derive(PartialEq, Eq)]`.
Fixes https://github.com/rust-lang/rust/issues/70790.
r? @estebank
Check code blocks tags
Fixes#71347.
Explanations here: I realized recently that it was a common issue to confuse/misspell tags on code blocks. This is actually quite a big issue since it generally ends up in a code blocks being ignored since it's not being considered as a rust one. With this new warning, users will at least be notified about it.
PS: some improvements can be done on the error rendering but considering how big the PR already is, I think it's better to do it afterwards.
r? @ollie27
cc @rust-lang/rustdoc
