remove interior mutability of type-flags
We were previously using the flags on `Ty<'tcx>` instances to do some ad-hoc caching schemes around things like `is_sized()`, `is_freeze()`, and `moves_by_default()`. This PR replaces those schemes with a proper query; the query key is based on the pair of a `(ParameterEnvironment<'tcx>, Ty<'tcx>)` pair. This is also intended to be a preliminary template for what trait-selection and projection will eventually look like.
I did some performance measurements. In the past, I observed a noticeable speedup (6%) for building rustc, but since I've rebased, the numbers appear to be more of a wash:
| Crate | Before | After | Percentage |
| --- | --- | --- | -- |
| syntax | 167s | 166s | 0.6% faster |
| rustc | 376s | 382s | 1.5% slower |
Some advantages of this new scheme:
- `is_sized` etc are proper queries
- we get caching across generic fns, so long as trait environment is identical
- dependency tracking is correct
Add better error message when == operator is badly used
Part of #40660.
With the following code:
```rust
fn foo<T: PartialEq>(a: &T, b: T) {
a == b;
}
fn main() {
foo(&1, 1);
}
```
It prints:
```
error[E0277]: the trait bound `&T: std::cmp::PartialEq<T>` is not satisfied
--> test.rs:2:5
|
2 | a == b;
| ^^^^^^ can't compare `&T` with `T`
|
= help: the trait `std::cmp::PartialEq<T>` is not implemented for `&T`
= help: consider adding a `where &T: std::cmp::PartialEq<T>` bound
error: aborting due to previous error
```
Use the trait-environment+type as the key. Note that these
are only invoked on types that live for the entire compilation
(no inference artifacts). We no longer need the various special-case
bits and caches that were in place before.
See #41444. As a first step towards untangling `ParameterEnvironment`, change
its `caller_bounds` field from a `Vec` into an interned slice of
`ty::Predicate`s.
This change is intentionally well-contained and doesn't pull on any of the
loose ends. In particular, you'll note that `normalize_param_env_or_error`
now interns twice.
On demandify region mapping
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
- makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)`
- interns code extents instead of of having them be integers
- remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer).
I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places.
2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query.
3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information).
Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect.
r? @eddyb
Clean up callable type mismatch errors
```rust
error[E0593]: closure takes 1 argument but 2 arguments are required here
--> ../../src/test/ui/mismatched_types/closure-arg-count.rs:13:15
|
13 | [1, 2, 3].sort_by(|(tuple, tuple2)| panic!());
| ^^^^^^^ -------------------------- takes 1 argument
| |
| expected closure that takes 2 arguments
```
instead of
```rust
error[E0281]: type mismatch: the type `[closure@../../src/test/ui/mismatched_types/closure-arg-count.rs:13:23: 13:49]` implements the trait `for<'r> std::ops::FnMut<(&'r {integer},)>`, but the trait `for<'r, 'r> std::ops::FnMut<(&'r {integer}, &'r {integer})>` is required (expected a tuple with 2 elements, found one with 1 elements)
--> ../../src/test/ui/mismatched_types/closure-arg-count.rs:13:15
|
13 | [1, 2, 3].sort_by(|(tuple, tuple2)| panic!());
| ^^^^^^^
```
Fix#21857, re #24680.
Instead of requesting the region maps for the entire crate, request for
a given item etc. Several bits of code were modified to take
`&RegionMaps` as input (e.g., the `resolve_regions_and_report_errors()`
function). I am not totally happy with this setup -- I *think* I'd
rather have the region maps be part of typeck tables -- but at least the
`RegionMaps` works in a "parallel" way to `FreeRegionMap`, so it's not
too bad. Given that I expect a lot of this code to go away with NLL, I
didn't want to invest *too* much energy tweaking it.
#37653 support `default impl` for specialization
this commit implements the first step of the `default impl` feature:
> all items in a `default impl` are (implicitly) `default` and hence
> specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See [referenced](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @aturon
Improve the librustc on-demand/query API ergonomics.
Queries are now performed through these two forms:
* `tcx.type_of(def_id)` (the most common usage)
* `tcx.at(span).type_of(def_id)` (to provide a more specific location in the cycle stack)
Several queries were renamed to work better as method names, i.e. by suffixing with `_of`.
r? @nikomatsakis
this commit implements the first step of the `default impl` feature:
all items in a `default impl` are (implicitly) `default` and hence
specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See referenced issue for further info
traits::select: quickly filter out predicates from other traits
this improves most pre-trans passes's performance by ~1%.
That missed the spring cleaning PR because I wanted to ship it.
r? @eddyb
In some cases (e.g. <[int-var] as Add<[int-var]>>), selection can turn up
a large number of candidates. Bailing out early avoids O(n^2) performance.
This improves item-type checking time by quite a bit, resulting in ~2% of total
time-to-typeck.
Arguably these could become custom queries, but I chose not to do that
because the relationship of queries and trait system is not yet fleshed
out enough. For now it seems fine to have them be `DepTrackingMap` using
the memoize pattern.
Fix ICE building gluon_vm
The problem was due to various places we were failing to propagate obligations. I think I got them mostly correct, but I didn't get around to writing test cases for each case.
r? @eddyb or @arielb1
Add a way to get shorter spans until `char` for pointing at defs
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| ^^^^^^^^ recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
vs
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| _^ starting here...
11 | | x: X,
12 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
Re: #35965, #38246. Follow up to #38328.
r? @jonathandturner
Ban registering obligations during InferCtxt snapshots.
Back in #33852, a flag was added to `InferCtxt` to prevent rolling back a snapshot if obligations were added to some `FulfillmentContext` during the snapshot, to prevent leaking fresh inference variables (created during that snapshot, so their indices would get reused) in obligations, which could ICE or worse.
But that isn't enough in the long run, as type-checking ends up relying on success implying that eager side-effects are fine, and while stray obligations *do* get caught nowadays, those errors prevent, e.g. the speculative coercions from #37658, which *have to* be rolled back *even* if they succeed.
We can't just allow those obligations to stay around though, because we end up, again, in ICEs or worse.
Instead, this PR modifies `lookup_method_in_trait_adjusted` to return `InferOk` containing the obligations that `Autoderef::finalize_as_infer_ok` can propagate to deref coercions.
As there shouldn't be *anything* left that registers obligations during snapshots, it's completely banned.
r? @nikomatsakis @arielb1
