| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The non-global context was removed; there's only one context now. This
is a noop method that only serves to confuse readers -- remove it.
|
|
|
|
|
|
Closes rust-lang/rfcs#1428
|
|
|
|
Remove unnecessary lift calls
Note that some of these might be useful for sanity checking that there's no infer types or regions.
r? @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change-Id: I3fa00e999a2ee4eb72db1fdf53a8633b49176a18
|
|
|
|
Make `intern_lazy_const` actually intern its argument.
Currently it just unconditionally allocates it in the arena.
For a "Clean Check" build of the the `packed-simd` benchmark, this
change reduces both the `max-rss` and `faults` counts by 59%; it
slightly (~3%) increases the instruction counts but the `wall-time` is
unchanged.
For the same builds of a few other benchmarks, `max-rss` and `faults`
drop by 1--5%, but instruction counts and `wall-time` changes are in the
noise.
Fixes #57432, fixes #57829.
|
|
Currently it just unconditionally allocates it in the arena.
For a "Clean Check" build of the the `packed-simd` benchmark, this
change reduces both the `max-rss` and `faults` counts by 59%; it
slightly (~3%) increases the instruction counts but the `wall-time` is
unchanged.
For the same builds of a few other benchmarks, `max-rss` and `faults`
drop by 1--5%, but instruction counts and `wall-time` changes are in the
noise.
Fixes #57432, fixes #57829.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`Result` really sounds like the rustc result type
|
|
|
|
|
|
tristanburgess:52985_diagnostics_no_concrete_type_behind_existential_type, r=oli-obk
52985 diagnostics no concrete type behind existential type
@oli-obk FYI. See below for new cycle error generated.
```rust
error[E0391]: cycle detected when processing `Foo`
--> /dev/staging/existential_type_no_concrete_type_nouse_potential.rs:3:1
|
3 | existential type Foo: Copy;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: ...which requires processing `bar`...
--> /dev/staging/existential_type_no_concrete_type_nouse_potential.rs:6:23
|
6 | fn bar(x: Foo) -> Foo {
| _______________________^
7 | | x
8 | | }
| |_^
= note: ...which again requires processing `Foo`, completing the cycle
error: aborting due to previous error
For more information about this error, try `rustc --explain E0391`.
```
|
|
|
|
|
|
- Original cycle error diagnostics PR'd against this issue caught
panic-causing error while resolving std::mem::transmute calls
- Now, catch invalid use case of not providing a concrete sized type
behind existential type in definining use case.
- Update relevant test to reflect this new error
52985: revert normalize query changes
- PR 53588 invalidates 53316, causing a correct cycle error to occur
with a good span.
- Don't need to revert the whole merge as the test files are
still fine, just need to revert the normalize query changes.
- It should now be correct that infinite recursion detected during
normalize query type folding is a bug, should have been caught earlier
(when resolving the existential type's defining use cases).
52985: code review impl
- Only cause cycle error if anonymous type resolves to anonymous type
that has the same def id (is the same type) as the original (parent)
type.
- Add test case to cover this case for existential types.
52985: remove Ty prefix from TyAnon
- To align with changes per commit 6f637da50c56a22f745fd056691da8c86824cd9b
|
|
Ty{Adt|Array|Slice|RawPtr|Ref|FnDef|FnPtr|Dynamic|Closure|Generator|GeneratorWitness|Never|Tuple|Projection|Anon|Infer|Error}
|
|
- If an existential type is defined, but no user code infers the
concrete type behind the existential type, normalization would
infinitely recurse on this existential type which is only defined in
terms of itself.
- Instead of raising an inf recurse error, we cause a cycle error to
help highlight that the issue is that the type is only defined in terms
of itself.
- Three known potential improvements:
- If type folding itself was exposed as a query, used by
normalization and other mechanisms, cases that would cause infinite recursion would
automatically cause a cycle error.
- The span for the cycle error should be improved to point to user
code that fails to allow inference of the concrete type of the existential type,
assuming that this error occurs because no user code can allow inference the
concrete type.
- A mechanism to extend the cycle error with a helpful note would be nice. Currently,
the error is built and maintained by src/librustc/ty/query/plumbing,
with no known way to extend the information that the error gets built
with.
|
|
Extra allocations are a significant cost of NLL, and the most common
ones come from within `Canonicalizer`. In particular, `canonical_var()`
contains this code:
indices
.entry(kind)
.or_insert_with(|| {
let cvar1 = variables.push(info);
let cvar2 = var_values.push(kind);
assert_eq!(cvar1, cvar2);
cvar1
})
.clone()
`variables` and `var_values` are `Vec`s. `indices` is a `HashMap` used
to track what elements have been inserted into `var_values`. If `kind`
hasn't been seen before, `indices`, `variables` and `var_values` all get
a new element. (The number of elements in each container is always the
same.) This results in lots of allocations.
In practice, most of the time these containers only end up holding a few
elements. This PR changes them to avoid heap allocations in the common
case, by changing the `Vec`s to `SmallVec`s and only using `indices`
once enough elements are present. (When the number of elements is small,
a direct linear search of `var_values` is as good or better than a
hashmap lookup.)
The changes to `variables` are straightforward and contained within
`Canonicalizer`. The changes to `indices` are more complex but also
contained within `Canonicalizer`. The changes to `var_values` are more
intrusive because they require defining a new type
`SmallCanonicalVarValues` -- which is to `CanonicalVarValues` as
`SmallVec` is to `Vec -- and passing stack-allocated values of that type
in from outside.
All this speeds up a number of NLL "check" builds, the best by 2%.
|
|
|
|
|
|
|
|
convert NLL ops to caches
This is a extension of <https://github.com/rust-lang/rust/pull/51460>. It uses a lot more caching than we used to do. This caching is not yet as efficient as it could be, but I'm curious to see the current perf results.
This is the high-level idea: in the MIR type checker, use [canonicalized queries](https://rust-lang-nursery.github.io/rustc-guide/traits/canonical-queries.html) for all the major operations. This is helpful because the MIR type check is operating in a context where all types are fully known (mostly, anyway) but regions are completely renumbered. This means we often wind up with duplicate queries like `Foo<'1, '2> :Bar` and `Foo<'3, '4>: Bar`. Canonicalized queries let us re-use the results. By the final commit in this PR, we can essentially just "read off" the resulting region relations and add them to the NLL type check.
|
|
|
|
|
|
This lets us simplify a few type aliases.
|
|
|
|
|
