| Age | Commit message (Collapse) | Author | Lines |
|
Remove `QueryEngine` trait
This removes the `QueryEngine` trait and `Queries` from `rustc_query_impl` and replaced them with function pointers and fields in `QuerySystem`. As a side effect `OnDiskCache` is moved back into `rustc_middle` and the `OnDiskCache` trait is also removed.
This has a couple of benefits.
- `TyCtxt` is used in the query system instead of the removed `QueryCtxt` which is larger.
- Function pointers are more flexible to work with. A variant of https://github.com/rust-lang/rust/pull/107802 is included which avoids the double indirection. For https://github.com/rust-lang/rust/pull/108938 we can name entry point `__rust_end_short_backtrace` to avoid some overhead. For https://github.com/rust-lang/rust/pull/108062 it avoids the duplicate `QueryEngine` structs.
- `QueryContext` now implements `DepContext` which avoids many `dep_context()` calls in `rustc_query_system`.
- The `rustc_driver` size is reduced by 0.33%, hopefully that means some bootstrap improvements.
- This avoids the unsafe code around the `QueryEngine` trait.
r? `@cjgillot`
|
|
|
|
|
|
Encoder/decoder cleanups
Best reviewed one commit at a time.
r? ``@scottmcm``
|
|
|
|
I was curious about how many `Encodable`/`Decodable` derives we have.
Some grepping revealed that it's over 500 of each, but the number of
`Encodable` ones was higher, which was weird. Most of the
`Encodable`-only ones were in `hir.rs`. This commit removes them all,
plus some other unnecessary derives in that file and others that I found
via trial and error.
|
|
More `Typefoldable`/`TypeVisitable` cleanups
r? ``@lcnr``
|
|
|
|
|
|
|
|
|
|
Make some region folders a little stricter.
Because certain regions cannot occur in them.
r? ``@compiler-errors``
|
|
|
|
`ty::Binber::dummy` calls
|
|
a `Span`
|
|
|
|
|
|
|
|
|
|
Because the derived versions are good enough.
|
|
|
|
Rewrite MemDecoder around pointers not a slice
This is basically https://github.com/rust-lang/rust/pull/109910 but I'm being a lot more aggressive. The pointer-based structure means that it makes a lot more sense to absorb more complexity into `MemDecoder`, most of the diff is just complexity moving from one place to another.
The primary argument for this structure is that we only incur a single bounds check when doing multi-byte reads from a `MemDecoder`. With the slice-based implementation we need to do those with `data[position..position + len]` , which needs to account for `position + len` wrapping. It would be possible to dodge the first bounds check if we stored a slice that starts at `position`, but that would require updating the pointer and length on every read.
This PR also embeds the failure path in a separate function, which means that this PR should subsume all the perf wins observed in https://github.com/rust-lang/rust/pull/109867.
|
|
Because certain regions cannot occur in them.
|
|
Use `?0` notation for ty/ct/int/float/region vars
Aligns the notation for infer vars that T-types and friends most often uses for inference variables with the notation in the compiler (which is kinda a sigil nightmare IMO: `_#`) by adopting `?0` style infer vars.
This mostly affects debug output since verbose infer vars shouldn't show up in user-facing places.
Does this need an MCP? It's debug output, so I'm thinking no, but happy to open one. :thinking:
r? types
|
|
|
|
|
|
Consider polarity in new solver
It's kinda ugly to have a polarity check in all of the builtin impls -- I guess I could consider the polarity at the top of assemble-builtin but that would require adding a polarity fn to `GoalKind`...
:shrug: putting this up just so i dont forget, since it's needed to bootstrap core during coherence (this alone does not allow core to bootstrap though, additional work is needed!)
r? ``@lcnr``
|
|
Add `impl_tag!` macro to implement `Tag` for tagged pointer easily
r? `@Nilstrieb`
This should also lifts the need to think about safety from the callers (`impl_tag!` is robust (ish, see the macro issue)) and removes the possibility of making a "weird" `Tag` impl.
|
|
r=compiler-errors
Switch to `EarlyBinder` for `explicit_item_bounds`
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
This PR adds `EarlyBinder` to the return type of the `explicit_item_bounds` query and removes `bound_explicit_item_bounds`.
r? `@compiler-errors` (hope it's okay to request you, since you reviewed #110299 and #110498 :smiley:)
|
|
|
|
|
|
|
|
In rust `new`-ish functions are usually the first ones in an `impl` block
|
|
|
|
This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
|
|
|
|
Add size asserts for MIR `SourceScopeData` & `VarDebugInfo`
There's vectors of both of these in `mir::Body`, so might as well track them.
(I was pondering adding something to one or the other, so wanted this to see the memory impact.)
|
|
|
|
|
|
r=b-naber
Remove `find_map_relevant_impl`
Fixes #108895
|
|
There's vectors of both of these in `mir::Body`, so might as well track them.
|
|
|
|
Run various queries from other queries instead of explicitly in phases
These are just legacy leftovers from when rustc didn't have a query system. While there are more cleanups of this sort that can be done here, I want to land them in smaller steps.
This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can invoke e.g. const eval which invokes borrowck, which invokes typeck, ...
|
|
Report allocation errors as panics
OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`.
This should be review one commit at a time:
- The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics.
- The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API.
ACP: https://github.com/rust-lang/libs-team/issues/192
Closes #51540
Closes #51245
|
|
Evaluate place expression in `PlaceMention`
https://github.com/rust-lang/rust/pull/102256 introduces a `PlaceMention(place)` MIR statement which keep trace of `let _ = place` statements from surface rust, but without semantics.
This PR proposes to change the behaviour of `let _ =` patterns with respect to the borrow-checker to verify that the bound place is live.
Specifically, consider this code:
```rust
let _ = {
let a = 5;
&a
};
```
This passes borrowck without error on stable. Meanwhile, replacing `_` by `_: _` or `_p` errors with "error[E0597]: `a` does not live long enough", [see playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c448d25a7c205dc95a0967fe96bccce8).
This PR *does not* change how `_` patterns behave with respect to initializedness: it remains ok to bind a moved-from place to `_`.
The relevant test is `tests/ui/borrowck/let_underscore_temporary.rs`. Crater check found no regression.
For consistency, this PR changes miri to evaluate the place found in `PlaceMention`, and report eventual dangling pointers found within it.
r? `@RalfJung`
|
|
Rollup of 7 pull requests
Successful merges:
- #109949 (rustdoc: migrate `document_type_layout` to askama)
- #110622 (Stable hash tag (discriminant) of `GenericArg`)
- #110635 (More `IS_ZST` in `library`)
- #110640 (compiler/rustc_target: Raise m68k-linux-gnu baseline to 68020)
- #110657 (nit: consistent naming for SimplifyConstCondition)
- #110659 (rustdoc: clean up JS)
- #110660 (Print ty placeholders pretty)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=wesleywiser,BoxyUwU
Print ty placeholders pretty
Makes anon placeholders print like `!0` instead of `Placeholder { ... }`.
```
rustc_trait_selection::solve::compute_well_formed_goal goal=Goal{
predicate: !0,
param_env: ParamEnv{
caller_bounds: [
Binder(TraitPredicate(<!0 as std::marker::Copy>, polarity: Positive), []),
Binder(TraitPredicate(<!0 as std::clone::Clone>, polarity: Positive), []),
Binder(TraitPredicate(<!0 as std::marker::Sized>, polarity: Positive), []),
],
reveal: UserFacing,
constness: NotConst,
}
}
```
cc `@BoxyUwU` who might care about this formatting decision
|
|
Stable hash tag (discriminant) of `GenericArg`
This is a continuation of my quest of removing `transmute` if generic args and types (#110496, #110599).
r? `@compiler-errors`
|
|
|
|
Add offset_of! macro (RFC 3308)
Implements https://github.com/rust-lang/rfcs/pull/3308 (tracking issue #106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented:
* Nested field accesses (without array indexing)
* DST support (for `Sized` fields)
I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it.
cc `@thomcc` (RFC author)
|