| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
This mostly reverts commit 7449478c2f6fd2d72c12a51d8562f1e6108facab.
It also removes an `opt_param_at` that really is unnecessary given our
ICE policy for malformed intrinsics.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MIR operators: clarify Shl/Shr handling of negative offsets
"made unsigned" was not fully clear (made unsigned how? by using `abs`? no), so let's say "re-interpreted as an unsigned value of the same size" instead.
r? `@scottmcm`
|
|
|
|
coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed
This code for recalculating `mcdc_bitmap_bytes` in a query doesn't provide any benefit, because its result won't have changed from the value in `FunctionCoverageInfo` that was computed during the MIR instrumentation pass.
Extracted from #124571, to avoid having this held up by unrelated issues with condition count checks.
`@rustbot` label +A-code-coverage
|
|
r=compiler-errors
Also expand weak alias tys inside consts inside `expand_weak_alias_tys`
Ever since #121344 has been merged, I couldn't let go of the fear that I might've slipped a tiny bug into rustc (:P).
Checking the type flags of the `Const` is strictly more correct than only checking the ones of the `Const`'s `Ty`. I don't think it's possible to trigger an ICE rn (i.e., one of the two `bug!("unexpected weak alias type")` I added in branches where `expand_weak_alias_tys` should've expanded *all* weak alias tys) because presently const exprs aren't allowed to capture late-bound vars. To be future-proof however, we should iron this out.
A possible reproducer would be the following if I'm not mistaken (currently fails to compile due to the aforementioned restriction):
```rs
#![feature(lazy_type_alias, adt_const_params, generic_const_exprs)]
type F = for<'a> fn(A<{ S::<Weak<'a>>(loop {}) }>) -> &'a ();
type A<const N: S<Weak<'static>>> = ();
#[derive(PartialEq, Eq, std::marker::ConstParamTy)]
struct S<T>(T);
type Weak<'a> = &'a ();
```
Whether a late-bound region should actually be considered constrained by a const expr is a separate question — one which we don't need to answer until / unless we actually allow them in such contexts (probable answer: only inside the return exprs of a block but not inside the stmts).
r? oli-obk (he's not available rn but that's fine) or types or compiler
|
|
Uplift `AliasTy` and `AliasTerm`
Follow-up from #125076.
r? lcnr
|
|
These comments appear to be inspired by the similar comments on
`CounterIncrement` and `ExpressionUsed`. But those comments refer to specific
simplification steps performed during coverage codegen, and there is no
corresponding step for the MC/DC coverage statements.
If these statements do not survive optimization, they will simply not
participate in code generation, just like any other statement.
|
|
This code for recalculating `mcdc_bitmap_bytes` doesn't provide any benefit,
because its result won't have changed from the value in `FunctionCoverageInfo`
that was computed during the MIR instrumentation pass.
|
|
|
|
This currently has no effect, but is expected to be useful when expanding
support for branch coverage and MC/DC coverage.
|
|
|
|
|
|
Split out `ty::AliasTerm` from `ty::AliasTy`
Splitting out `AliasTerm` (for use in project and normalizes goals) and `AliasTy` (for use in `ty::Alias`)
r? lcnr
|
|
|
|
|
|
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.
The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
Add `size_of_val`, `align_of`, and `align_of_val` as well, with similar
justification: widely useful, self-explanatory, unmistakeable for
anything else, won't produce conflicts.
|
|
|
|
Remove `#[macro_use] extern crate rustc middle` from numerous crates
Because explicit importing of macros via `use` items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. This PR mops up some cases I didn't get to in #124511.
r? `@saethlin`
|
|
This requires exporting the interpreter macros so they can be used with
`use crate::interpret::*`.
|
|
Jules-Bertholet:match-ergonomics-2024-migration-lint, r=Nadrieril
Match ergonomics 2024: migration lint
Depends on #124567
r? `@Nadrieril`
cc https://github.com/rust-lang/rust/issues/123076
`@rustbot` label A-edition-2024 A-patterns
|
|
Unfortunately, we can't always offer a machine-applicable suggestion when there are subpatterns from macro expansion.
Co-Authored-By: Guillaume Boisseau <Nadrieril@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Uplift `TraitRef` into `rustc_type_ir`
Emotional rollercoaster
r? lcnr
|
|
|
|
|
|
|
|
|
|
Rename some `FulfillmentErrorCode`/`ObligationCauseCode` variants to be less redundant
1. Rename some `FulfillmentErrorCode` variants.
2. Always use `ObligationCauseCode::` to prefix a code, rather than using a glob import and naming them through `traits::`.
3. Rename some `ObligationCauseCode` variants -- I wasn't particularly thorough with thinking of a new names for these, so could workshop them if necessary.
4. Misc stuff from renaming.
r? lcnr
|
|
|
|
|
|
|
|
|
|
Make `Ty::builtin_deref` just return a `Ty`
Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
|
|
Refactor float `Primitive`s to a separate `Float` type
Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`.
As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`.
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
|
