| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Operand: 72 -> 24 B
Statement: 192 -> 96 B
Terminator: 256 -> 112 B
librustc translation memory usage: 1795 -> 1669 MB
next step would be interning lvalues, I suppose?
|
|
Fixes #41849. Problem was that evaluating the constant expression
required evaluating a trait, which would equate types, which would
request variance information, which it would then discard. However,
computing the variance information would require determining the type of
a field, which would evaluate the constant expression.
(This problem will potentially arise *later* as we move to more sophisticated
constants, however, where we need to check subtyping. We can tackle that
when we come to it.)
|
|
This seems both to be a safe, conservative choice,
and it sidesteps the cycle in #41936.
Fixes #41936.
|
|
|
|
|
|
`try_index_step` does not resolve type variables by itself and would
fail otherwise. Also harden the failure path in `confirm` to cause less
confusing errors.
|
|
|
|
|
|
|
|
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
|
|
This avoids visiting the fields of all structs multiple times, improving
item-bodies checking time by 10% (!).
|
|
this improves most pre-trans passes's performance by ~1%.
|
|
|
|
|
|
|
|
|
|
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.
|
|
this is another one of these things that looks *much* worse on valgrind.
|
|
improves trans performance by *another* 10%.
|
|
this avoids parsing item attributes on each call to `item_attrs`, which takes
off 33% (!) of translation time and 50% (!) of trans-item collection time.
|
|
That method is *incredibly* hot, so this ends up saving 10% of trans
time.
BTW, we really should be doing dependency tracking there - and possibly be
taking the respective perf hit (got to find a way to make DTMs fast), but
`layout_cache` is a non-dep-tracking map.
|
|
this improves typeck & trans performance by 1%. This looked hotter on
callgrind than it is on a CPU.
|
|
Rollup of 3 pull requests
- Successful merges: #41077, #41355, #41450
- Failed merges:
|
|
Implementation of repr struct alignment RFC 1358.
The main changes around rustc::ty::Layout::struct:
* Added abi_align field which stores abi alignment before repr align is applied
* align field contains transitive repr alignment
* Added padding vec which stores padding required after fields
The main user of this information is rustc_trans::adt::struct_llfields
which determines the LLVM fields to be used by LLVM, including padding
fields.
A possible future optimisation would be to put the padding Vec in an Option, since it will be unused unless you are using repr align.
|
|
This makes these routines more readily available for other bits of
code. It also will help when refactoring.
|
|
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.
|
|
Once it is computed, no need to deep clone the set.
|
|
This may seem like overkill, but it's exactly what we want/need for
incremental compilation I think. In particular, while generating code
for some codegen unit X, we can wind up querying about any number of
external items, and we only want to be forced to rebuild X is some of
those changed from a foreign item to otherwise. Factoring this into a
query means we would re-run only if some `false` became `true` (or vice
versa).
|
|
The main changes around rustc::ty::Layout::struct and rustc_trans:adt:
* Added primitive_align field which stores alignment before repr align
* Always emit field padding when generating the LLVM struct fields
* Added methods for adjusting field indexes from the layout index to the
LLVM struct field index
The main user of this information is rustc_trans::adt::struct_llfields
which determines the LLVM fields to be used by LLVM, including padding
fields.
|
|
|
|
|
|
|
|
|
|
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
|
|
cc #32730 -- I left exactly one instance where I wasn't sure of the
right behavior.
|
|
|
|
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
|
|
Move E0101 and E0102 logic into new E0282 mechanism #40013
Hello there!
## What's this?
Previously, me and @nikomatsakis worked on error messages of uninferred locals. (#38812)
This aims to build up on that by moving certain type checks from `writeback`.
With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown.
They're replaced with customized versions of `E0282`s instead.
## Sample Error Messages
#### `E0101` is getting converted into:
```rust
error[E0282]: type annotations needed
--> test.rs:2:14
|
2 | let x = |_| {};
| ^ consider giving this closure parameter a type
error: aborting due to previous error
```
#### `E0102` is getting converted into:
```rust
error[E0282]: type annotations needed
--> test.rs:2:9
|
2 | let x = [];
| ^
| |
| consider giving `x` a type
| cannot infer type for `[_; 0]`
error: aborting due to previous error
```
## Annoyances
- I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO.
- I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this.
## Tests
Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests.
## Documentation
Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones.
Please do comment on messages, layouts and other details.
## Appreciation
Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
|
|
|
|
|
|
|
|
|
|
We no longer need to track the tasks in these cases since these
particular tasks have no outputs (except, potentially, errors...) and
they always execute.
|
|
Rollup of 3 pull requests
- Successful merges: #41262, #41310, #41344
- Failed merges:
|
|
[on-demand] Turn monomorphic_const_eval into a proper query, not just a cache.
The error definitions and reporting logic, alongside with `eval_length` were moved to `librustc`.
Both local and cross-crate constant evaluation is on-demand now, but the latter is only used for `enum` discriminants, to replace the manual insertion into the cache which was done when decoding variants.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
