| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
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:)
|
|
This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
|
|
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
|
|
|
|
|
|
it eagerly.
Later queries that are run on all body owners will invoke typeck as they need information from its result to perform their own logic
|
|
instead of merging everything into a single bag.
If it's acceptable from performance point of view, then it's more clear to keep this stuff organized more in accordance with its use.
|
|
bound_explicit_item_bounds usages; remove bound_explicit_item_bounds query
|
|
|
|
|
|
|
|
collect_return_position_impl_trait_in_trait_tys query; remove bound_X version
|
|
|
|
Remove `remap_env_constness` in queries
This removes some of the complexities with const traits. #88119 used to be caused by this but was fixed by `param_env = param_env.without_const()`.
|
|
resolve: Pre-compute non-reexport module children
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
|
|
Fix typos in compiler
I ran [`typos -w compiler`](https://github.com/crate-ci/typos) to fix typos in the `compiler` directory.
Refs #110150
|
|
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list.
They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
|
|
|
|
|
|
|
|
|
|
This may be potentially useful for
- avoiding uses of `hir::ItemKind::Use`
- preserving documentation comments on all reexports
- preserving and checking stability/deprecation info on reexports
- all kinds of diagnostics
|
|
|
|
Erase query cache values
This replaces most concrete query values `V` with `MaybeUninit<[u8; { size_of::<V>() }]>` without introducing dynamic dispatch like https://github.com/rust-lang/rust/pull/108638 does. This is split out of https://github.com/rust-lang/rust/pull/108638 so the performance impact of only this change can be measured.
r? `@cjgillot`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The first PR for https://github.com/rust-lang/compiler-team/issues/606
This is just the move-and-rename, because it's plenty big-and-bitrotty already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
|
|
It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.
Crate-level cfg attributes are then expanded normally during the main expansion pass, like attributes on any other nodes.
|
|
|
|
|
|
|
|
|
|
|
|
Install projection from RPITIT to default trait method opaque correctly
1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!
2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.
3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.
r? ````@spastorino,```` based off of #109140
|
|
Unequal → Not equal
Fixes #109168
|
|
|
|
|
|
Use `unused_generic_params` from crate metadata
Due to the way that `separate_provide_extern` interacted with the implementation of `<ty::InstanceDef<'tcx> as Key>::query_crate_is_local`, we actually never hit the foreign provider for `unused_generic_params`.
Additionally, since the *local* provider of `unused_generic_params` calls `should_polymorphize`, which always returns false if the def-id is foreign, this means that we never actually polymorphize monomorphic instances originating from foreign crates.
We don't actually encode `unused_generic_params` for items where all generics are used, so I had to tweak the foreign provider to fall back to `ty::UnusedGenericParams::new_all_used()` to avoid more ICEs when the above bugs were fixed.
|
|
|
|
|
