| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
new solver)
|
|
|
|
r=oli-obk,compiler-errors
Clarify iterator interners
I found the iterator interners very confusing. This PR clarifies things.
r? `@compiler-errors`
|
|
Remove `arena_cache` modifier from `associated_item` query & copy `ty::AssocItem` instead of passing by ref
r? `@ghost`
|
|
This function has this line twice:
```
let bound_vars = tcx.intern_bound_variable_kinds(&bound_vars);
```
The second occurrence is effectively a no-op, because the first
occurrence interned any that needed it.
|
|
|
|
This makes a lot of call sites nicer.
|
|
`InternIteratorElement` is a trait used to intern values produces by
iterators. There are three impls, corresponding to iterators that
produce different types:
- One for `T`, which operates straightforwardly.
- One for `Result<T, E>`, which is fallible, and will fail early with an
error result if any of the iterator elements are errors.
- One for `&'a T`, which clones the items as it iterates.
That last one is bad: it's extremely easy to use it without realizing
that it clones, which goes against Rust's normal "explicit is better"
approach to cloning.
So this commit just removes it. In practice, there weren't many use
sites. For all but one of them `into_iter()` could be used, which avoids
the need for cloning. And for the one remaining case `copied()` is
used.
|
|
There are several `mk_foo`/`intern_foo` pairs, where the former takes an
iterator and the latter takes a slice. (This naming convention is bad,
but that's a fix for another PR.)
This commit changes several `mk_foo` occurrences into `intern_foo`,
avoiding the need for some `.iter()`/`.into_iter()` calls. Affected
cases:
- mk_type_list
- mk_tup
- mk_substs
- mk_const_list
|
|
|
|
|
|
Switch to `EarlyBinder` for `type_of` query
Part of the work to finish #105779 and implement https://github.com/rust-lang/types-team/issues/78.
Several queries `X` have a `bound_X` variant that wraps the output in `EarlyBinder`. This adds `EarlyBinder` to the return type of the `type_of` query and removes `bound_type_of`.
r? `@lcnr`
|
|
|
|
in metadata
|
|
|
|
r=compiler-errors
Do not ICE on unmet trait alias impl bounds
Fixes #108132
I've also added some documentation to the `impl_def_id` field of `DerivedObligationCause` to try and minimise the risk of such errors in future.
r? `@compiler-errors`
|
|
Implement partial support for non-lifetime binders
This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.
Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.
Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)
cc rust-lang/types-team#81
r? `@ghost`
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #106347 (More accurate spans for arg removal suggestion)
- #108057 (Prevent some attributes from being merged with others on reexports)
- #108090 (`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`)
- #108092 (note issue for feature(packed_bundled_libs))
- #108099 (use chars instead of strings where applicable)
- #108115 (Do not ICE on unmet trait alias bounds)
- #108125 (Add new people to the compiletest review rotation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Optimize `mk_region`
PR #107869 avoiding some interning under `mk_ty` by special-casing `Ty` variants with simple (integer) bodies. This PR does something similar for regions.
r? `@compiler-errors`
|
|
|
|
|
|
don't clone types that are copy
|
|
|
|
|
|
Use `target` instead of `machine` for mir interpreter integer handling.
The naming of `machine` only makes sense from a mir interpreter internals perspective, but outside users talk about the `target` platform. As per https://github.com/rust-lang/rust/pull/108029#issuecomment-1429791015
r? `@RalfJung`
|
|
Make `InferCtxt::can_eq` and `InferCtxt::can_sub` return booleans
Nobody matches on the result, nor does the result return anything useful...
|
|
|
|
The naming of `machine` only makes sense from a mir interpreter internals perspective, but outside users talk about the `target` platform
|
|
r=compiler-errors
use semantic equality for const param type equality assertion
Fixes #107898
See added test for what caused this ICE
---
The current in assertion in `relate.rs` is rather inadequate when keeping in mind future expansions to const generics:
- it will ICE when there are infer vars in a projection in a const param ty
- it will spurriously return false when either ty has infer vars because of using `==` instead of `infcx.at(..).eq`
- i am also unsure if it would be possible with `adt_const_params` to craft a situation where the const param type is not wf causing `normalize_erasing_regions` to `bug!` when we would have emitted a diagnostic.
This impl feels pretty Not Great to me although i am not sure what a better idea would be.
- We have to have the logic behind a query because neither `relate.rs` or `combine.rs` have access to trait solving machinery (without evaluating nested obligations this assert will become _far_ less useful under lazy norm, which consts are already doing)
- `relate.rs` does not have access to canonicalization machinery which is necessary in order to have types potentially containing infer vars in query arguments.
We could possible add a method to `TypeRelation` to do this assertion rather than a query but to avoid implementing the same logic over and over we'd probably end up with the logic in a free function somewhere in `rustc_trait_selection` _anyway_ so I don't think that would be much better.
We could also just remove this assertion, it should not actually be necessary for it to be present. It has caught some bugs in the past though so if possible I would like to keep it.
r? `@compiler-errors`
|
|
Much like there are specialized variants of `mk_ty`. This will enable
some optimization in the next commit.
Also rename the existing `re_error*` functions as `mk_re_error*`, for
consistency.
|
|
Rollup of 9 pull requests
Successful merges:
- #107573 (Update the minimum external LLVM to 14)
- #107626 (Fix `x fix` on the standard library itself)
- #107673 (update ICU4X to 1.1.0)
- #107733 (Store metrics from `metrics.json` to CI PGO timer)
- #108007 (Use `is_str` instead of string kind comparison)
- #108033 (add an unstable `#[rustc_coinductive]` attribute)
- #108039 (Refactor refcounted structural_impls via functors)
- #108040 (Use derive attributes for uninteresting traversals)
- #108044 (interpret: rename Pointer::from_addr → from_addr_invalid)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add an unstable `#[rustc_coinductive]` attribute
useful to test coinduction, especially in the new solver.
as this attribute should remain permanently unstable I don't think this needs any official approval. cc ``@rust-lang/types``
had to weaken the check for stable query results in the solver to prevent an ICE if there's a coinductive cycle with constraints.
r? ``@compiler-errors``
|
|
s/eval_usize/eval_target_usize/ for clarity
r? `@nnethercote`
as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60Const.60.20and.20.60usize.60.2F.60u64.60 it is unclear what `usize` means and why we use a `u64` for something talking about `usize`. This renaming should make it clear that we're talking about `usize`s on the target platform, irrespective of the compiler host platform.
|
|
r=lcnr
Check for overflow in evaluate_canonical_goal
r? `@lcnr`
|
|
|
|
|
|
|
|
fix: Unexpected trait bound not satisfied in HRTB and Associated Type
fix https://github.com/rust-lang/rust/issues/103563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
