Use assoc int consts3
Define module level int consts with associated constants instead of `min_value()` and `max_value()`. So the code become consistent with what the docs recommend etc. Seems natural.
Also remove the last usages of the int module constants from this repo (except src/test/ directory which I have still not really done anything in). Some places were missed in the previous PRs because the code uses `crate::<IntTy>` to reach the constants.
This is a continuation of #70857
r? @dtolnay
Suggest `-> impl Trait` and `-> Box<dyn Trait>` on fn that doesn't return
During development, a function could have a return type set that is a
bare trait object by accident. We already suggest using either a boxed
trait object or `impl Trait` if the return paths will allow it. We now
do so too when there are *no* return paths or they all resolve to `!`.
We still don't handle cases where the trait object is *not* the entirety
of the return type gracefully.
Closes#38376.
Check that main/start is not async
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
This PR fixes#68523.
When the return type is `!Sized` we look for all the returned
expressions in the body to fetch their types and provide a reasonable
suggestion. The tail expression of the body is normally evaluated after
checking whether the return type is `Sized`. Changing the order of the
evaluation produces undesirable knock down effects, so we detect the
specific case that newcomers are likely to encounter ,returning a single
bare trait object, and only in that case we evaluate the tail
expression's type so that the suggestion will be accurate.
During development, a function could have a return type set that is a
bare trait object by accident. We already suggest using either a boxed
trait object or `impl Trait` if the return paths will allow it. We now
do so too when there are *no* return paths or they all resolve to `!`.
We still don't handle cases where the trait object is *not* the entirety
of the return type gracefully.
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
Fix formatting errors and bless test outputs
* move tests to ui/async-await
fix test error text
remove span from IsAsync
ty/print: pretty-print constant aggregates (arrays, tuples and ADTs).
Oddly enough, we don't have any UI tests showing this off in types, only `mir-opt` tests.
However, the pretty form should show up in the test output diff of #71018, if this PR is merged first.
<hr/>
Examples of before/after:
|`Option<bool>`|
|:-:|
|`{transmute(0x01): std::option::Option<bool>}`|
| ✨ ↓↓↓ ✨ |
|`std::option::Option::<bool>::Some(true)`|
| `RawVec<u32>` |
|:-:|
| `ByRef { alloc: Allocation { bytes: [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [] }), undef_mask: UndefMask { blocks: [65535], len: Size { raw: 16 } }, size: Size { raw: 16 }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::<u32>`|
| ✨ ↓↓↓ ✨ |
|`alloc::raw_vec::RawVec::<u32> { ptr: std::ptr::Unique::<u32> { pointer: {0x4 as *const u32}, _marker: std::marker::PhantomData::<u32> }, cap: 0usize, alloc: std::alloc::Global }`|
<hr/>
This PR is a prerequisite for #61486, *sort of*, in that we need to be able to pretty-print values in order to even consider how we might mangle them.
We still don't have pretty-printing for constants of reference types, @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
<hr/>
Each commit should be reviewed separately, as I've fixed a couple deficiencies along the way.
r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid
Deprecate the asm! macro in favor of llvm_asm!
Since we will be changing the syntax of `asm!` soon, deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed.
RFC: https://github.com/rust-lang/rfcs/pull/2843
Make `needs_drop` less pessimistic on generators
Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does.
This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications.
~~This builds off of https://github.com/rust-lang/rust/pull/69814 since that contains some fixes that are made relevant by *this* PR (see https://github.com/rust-lang/rust/pull/69814#issuecomment-599147269).~~ (this has been merged)
Maintain chain of derived obligations
When evaluating the derived obligations from super traits, maintain a
reference to the original obligation in order to give more actionable
context in the output.
Continuation (and built on) #69745, subset of #69709.
r? @eddyb
When evaluating the derived obligations from super traits, maintain a
reference to the original obligation in order to give more actionable
context in the output.
miri-unleashed: test that we detect heap allocations
This removes the second-to-last use of `IS_SUPPORTED_IN_MIRI = false`.
r? @ecstatic-morse @oli-obk
