| Age | Commit message (Collapse) | Author | Lines |
|---|
|
These operations are much more about lowering the HIR than about
`Const`s themselves. They fit better in hir_ty_lowering with
`lower_const_arg` (formerly `Const::from_const_arg`) and the rest.
To accomplish this, `const_evaluatable_predicates_of` had to be changed
to not use `from_anon_const` anymore. Instead of visiting the HIR and
lowering anon consts on the fly, it now visits the `rustc_middle::ty`
data structures instead and directly looks for `UnevaluatedConst`s. This
approach was proposed in:
https://github.com/rust-lang/rust/pull/131081#discussion_r1821189257
|
|
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #133589 (Remove `hir::ArrayLen`)
- #133672 (Remove a bunch of unnecessary const stability noise)
- #133678 (Stabilize `ptr::fn_addr_eq`)
- #133727 (Update mailmap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
|
|
coverage: Use a query to identify which counter/expression IDs are used
Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen.
This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function.
---
There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
|
|
|
|
|
|
|
|
|
|
Remove Node::ArrayLenInfer
|
|
|
|
|
|
There is unlikely to be any practical difference between a counter limit of
2^32 and a counter limit of (2^32 - 256).
|
|
support revealing defined opaque post borrowck
By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. ``@compiler-errors`` mentioned that always using existentials may be unsound.
r? ``@compiler-errors``
|
|
This reverts commit adf9b5fcd1de43eaf0a779e10612caee8b47bede, reversing
changes made to af1ca153d4aed5ffe22445273aa388a8d3f8f4ae.
Reverting due to <https://github.com/rust-lang/rust/issues/133606>.
|
|
this implements checks necessary to guarantee that we can actually
perform a tail call. while extremely restrictive, this is what is
documented in the RFC, and all these checks are needed for one reason or
another.
|
|
Enable -Zshare-generics for inline(never) functions
This avoids inlining cross-crate generic items when possible that are
already marked inline(never), implying that the author is not intending
for the function to be inlined by callers. As such, having a local copy
may make it easier for LLVM to optimize but mostly just adds to binary
bloat and codegen time. In practice our benchmarks indicate this is
indeed a win for larger compilations, where the extra cost in dynamic
linking to these symbols is diminished compared to the advantages in
fewer copies that need optimizing in each binary.
It might also make sense it expand this with other heuristics (e.g.,
`#[cold]`) in the future, but this seems like a good starting point.
FWIW, I expect that doing cleanup in where we make the decision
what should/shouldn't be shared is also a good idea. Way too
much code needed to be tweaked to check this. But I'm hoping
to leave that for a follow-up PR rather than blocking this on it.
|
|
This reduces code sizes and better respects programmer intent when
marking inline(never). Previously such a marking was essentially ignored
for generic functions, as we'd still inline them in remote crates.
|
|
|
|
coverage: Store coverage source regions as `Span` until codegen
Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead.
In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32.
---
There should be no changes to coverage output.
|
|
Some more refactorings towards removing driver queries
Follow up to https://github.com/rust-lang/rust/pull/127184
## Custom driver breaking change
The `after_analysis` callback is changed to accept `TyCtxt` instead of `Queries`. The only safe query in `Queries` to call at this point is `global_ctxt()` which allows you to enter the `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `tcx: TyCtxt<'tcx>` and remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
## Custom driver deprecation
The `after_crate_root_parsing` callback is now deprecated. Several custom drivers are incorrectly calling `queries.global_ctxt()` from inside of it, which causes some driver code to be skipped. As such I would like to either remove it in the future or if custom drivers still need it, change it to accept an `&rustc_ast::Crate` instead.
|
|
Remove -Zfuel.
I'm not sure this feature is used. I only found 2 references in a google search, both referring to its introduction.
Meanwhile, it's a global mutable state, untracked by incremental compilation, so incompatible with it.
|
|
Simplify array length mismatch error reporting (to not try to turn consts into target usizes)
This changes `TypeError::FixedArrayLen` to use `ExpectedFound<ty::Const<'tcx>>` (instead of `ExpectedFound<u64>`), and renames it to `TypeError::ArrayLen`. This allows us to avoid a `try_to_target_usize` call in the type relation, which ICEs when we have a scalar of the wrong bit length (i.e. u8).
This also makes `structurally_relate_tys` to always use this type error kind any time we have a const mismatch resulting from relating the array-len part of `[T; N]`.
This has the effect of changing the error message we issue for array length mismatches involving non-valtree consts. I actually quite like the change, though, since before:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected `M`, found `N`
|
= note: expected array `[u8; M]`
found array `[u8; N]`
```
and after, which I think is far less verbose:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected an array with a size of M, found one with a size of N
```
The only questions I have are:
1. Should we do something about backticks here? Right now we don't backtick either fully evaluated consts like `2`, or rigid consts like `Foo::BAR`.... but maybe we should? It seems kinda verbose to do for numbers -- maybe we could intercept those specifically.
2. I guess we may still run the risk of leaking unevaluated consts into error reporting like `2 + 1`...?
r? ``@BoxyUwU``
Fixes #126359
Fixes #131101
|
|
No need to re-sort existential preds in relate impl
We already assert that these predicates are in the right ordering in `mk_poly_existential_predicates`.
r? types
|
|
|
|
|
|
|
|
remove is_trivially_const_drop
I'm not sure this still brings any perf benefits, so let's benchmark this.
r? `@compiler-errors`
|
|
|
|
finish `Reveal` removal
After #133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.
cc #132279
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
|
|
Remove unnecessary bool from `ExpectedFound::new`
It's true almost everywhere, and the one place it's not can be replaced w/ an if statement.
|
|
Implement the unsafe-fields RFC.
RFC: rust-lang/rfcs#3458
Tracking:
- https://github.com/rust-lang/rust/issues/132922
r? jswrenn
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #132090 (Stop being so bail-y in candidate assembly)
- #132658 (Detect const in pattern with typo)
- #132911 (Pretty print async fn sugar in opaques and trait bounds)
- #133102 (aarch64 softfloat target: always pass floats in int registers)
- #133159 (Don't allow `-Zunstable-options` to take a value )
- #133208 (generate-copyright: Now generates a library file too.)
- #133215 (Fix missing submodule in `./x vendor`)
- #133264 (implement OsString::truncate)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
|
|
Implement `~const` item bounds in RPIT
an RPIT in a `const fn` is allowed to be conditionally const itself :)
r? fee1-dead or reroll
|
|
Rollup of 6 pull requests
Successful merges:
- #129838 (uefi: process: Add args support)
- #130800 (Mark `get_mut` and `set_position` in `std::io::Cursor` as const.)
- #132708 (Point at `const` definition when used instead of a binding in a `let` statement)
- #133226 (Make `PointerLike` opt-in instead of built-in)
- #133244 (Account for `wasm32v1-none` when exporting TLS symbols)
- #133257 (Add `UnordMap::clear` method)
r? `@ghost`
`@rustbot` modify labels: rollup
|
