| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Rename LayoutDetails to just Layout.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`delay_span_bug` when codegen cannot select obligation
Fix #69602, introduced in #60126 by letting the compiler continue past
type checking after encountering errors.
|
|
|
|
Fix #69602, introduced in #60126 by letting the compiler continue past
type checking after encountering errors.
|
|
Use a query to get parent modules
Split out from https://github.com/rust-lang/rust/pull/69015 / https://github.com/rust-lang/rust/pull/68944.
r? @michaelwoerister
|
|
|
|
|
|
Canonicalize inputs to const eval where needed
Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection.
This is a reattempt of #67717, in a far less invasive way.
Fixes #68477
r? @nikomatsakis
cc @eddyb
|
|
|
|
Querify object_safety_violations.
Split from #69076
r? @Zoxc
|
|
O(log n) lookup of associated items by name
Resolves #68957, in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result, the pathological case from that issue now runs in 8 seconds on my local machine, as opposed to many minutes on the current stable.
Currently, method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used, e.g., for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup, we first find all items with the same `Symbol` using binary search, then run hygienic comparison to find the one we are looking for. Ideally, this would be implemented using an insertion-order preserving, hash-based multi-map, but one is not readily available.
Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly, even if it seemed strange (I left at least one FIXME to this effect). For example, some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.
|
|
|
|
|
|
|
|
|
|
Change const eval to just return the value
As discussed in https://github.com/rust-lang/rust/pull/68505#discussion_r370956535, the type of consts shouldn't be returned from const eval queries.
r? @eddyb
cc @nikomatsakis
|
|
|
|
instead of `Const` as the type
in the returned const isn't needed.
|
|
|
|
|
|
Improve `ty.needs_drop`
* Handle cycles in `needs_drop` correctly
* Normalize types when computing `needs_drop`
* Move queries from rustc to rustc_ty
* Avoid query in simple cases
reopens #65918
|
|
|
|
|
|
|
|
Move the `hir().krate()` method to a query and remove the `Krate` dep node
r? @eddyb cc @michaelwoerister
|
|
|
|
|
|
|
|
|
|
* Handle cycles in `needs_drop` correctly
* Normalize types when computing `needs_drop`
* Move queries from rustc to rustc_ty
|
|
This reduces the amount of invalidated data when new types are
add to upstream crates.
|
|
Filter and test predicates using `normalize_and_test_predicates` for const-prop
Fixes #68264
Previously, I attempted to use
`substitute_normalize_and_test_predicates` to detect unsatisfiable
bounds. Unfortunately, since const-prop runs in a generic environment
(we don't have any of the function's generic parameters substituted),
this could lead to cycle errors when attempting to normalize predicates.
This check is replaced with a more precise check. We now only call
`normalize_and_test_predicates` on predicates that have the possibility
of being proved unsatisfiable - that is, predicates that don't depend
on anything local to the function (e.g. generic parameters). This
ensures that we don't hit cycle errors when we normalize said
predicates, while still ensuring that we detect unsatisfiable
predicates.
I haven't been able to come up with a minimization of the Diesel issue - however, I've verified that it compiles successfully.
|