| Age | Commit message (Collapse) | Author | Lines |
|
By boxing `user_ty`.
|
|
By boxing `local_info`.
|
|
|
|
This commit adds some new `LocalDecl` methods:
- `with_source_info`, a most general constructor.
- `new`, a variant of `with_source_info` which represents the most
common use case.
- `internal` a modifying method (like the already present `immutable`).
It removes some old `LocalDecl` methods:
- `new_internal` and `new_local`, because they're subsumed by the new
methods.
- `new_return_place`, because it was identical to `new_temp`.
Finally, it cleans up all the use sites.
|
|
|
|
shorter name)
|
|
|
|
By merging the undo_log of all structures part of the snapshot the cost
of creating a snapshot becomes much cheaper. Since snapshots with no or
few changes are so frequent this ends up mattering more than the slight
overhead of dispatching on the variants that map to each field.
|
|
|
|
add a missing "at" in a comment
|
|
|
|
When encountering a projection that isn't satisfied by a type parameter,
suggest constraining the type parameter.
|
|
|
|
Don't copy bytecode files into the incr. comp. cache.
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires, so I'm re-sending this patch!
|
|
On type mismatch involving associated type, suggest constraint
When an associated type is found when a specific type was expected, if
possible provide a structured suggestion constraining the associated
type in a bound.
```
error[E0271]: type mismatch resolving `<T as Foo>::Y == i32`
--> $DIR/associated-types-multiple-types-one-trait.rs:13:5
|
LL | want_y(t);
| ^^^^^^ expected `i32`, found associated type
...
LL | fn want_y<T:Foo<Y=i32>>(t: &T) { }
| ----- required by this bound in `want_y`
|
= note: expected type `i32`
found associated type `<T as Foo>::Y`
help: consider constraining the associated type `<T as Foo>::Y` to `i32`
|
LL | fn have_x_want_y<T:Foo<X=u32, Y = i32>>(t: &T)
| ^^^^^^^^^
```
```
error[E0308]: mismatched types
--> $DIR/trait-with-missing-associated-type-restriction.rs:12:9
|
LL | qux(x.func())
| ^^^^^^^^ expected `usize`, found associated type
|
= note: expected type `usize`
found associated type `<impl Trait as Trait>::A`
help: consider constraining the associated type `<impl Trait as Trait>::A` to `usize`
|
LL | fn foo(x: impl Trait<A = usize>) {
| ^^^^^^^^^^
```
Fix #71035. Related to #70908.
|
|
|
|
|
|
|
|
...emulating `MutatingUseContext::Call`
|
|
typeck: always expose explicit enum discriminant `AnonConst`s' parent in `generics_of`.
This is similar to #70452 but for explicit `enum` discriminant constant expressions.
However, unlike #70452, this PR should have no effect on stable code, as while it alleviates #43408 errors, there is no way to actually compile an `enum` with generic parameters *and* explicit discriminants, without `#![feature(arbitrary_enum_discriminant)]`, as explicit discriminant expression don't count as uses of parameters (if they did, they would count as invariant uses).
<hr/>
There's also 2 other commits here, both related to #70453:
* "ty: use `delay_span_bug` in `ty::AdtDef::eval_explicit_discr`." - hides the ICEs demonstrated on #70453, when there are other errors (which the next commit adds)
* "typeck/wfcheck: require that explicit enum discriminants const-evaluate succesfully." - closes #70453 by picking alternative "2", i.e. erroring when a discriminant doesn't fully const-evaluate from the perspective of the `enum` definition
In the future, it might be possible to allow `enum` discriminants to actually depend on parameters, but that will likely require #68436 + some way to restrict the values so no two variants can end up with overlapping discriminants.
As this PR would close #70453, it shouldn't be merged until a decision is reached there.
r? @nikomatsakis
|
|
|
|
Fix #71035.
|
|
|
|
Associated types with a default type in a trait can't be relied upon to
remain of that default type when in use, so literals of that type can't
be used in the trait's items. Point at the associated type and state
that information.
Reduce verbosity for associated consts of the wrong type.
|
|
|
|
|
|
When an associated type is found when a specific type was expected, if
possible provide a structured suggestion constraining the associated
type in a bound.
```
error[E0271]: type mismatch resolving `<T as Foo>::Y == i32`
--> $DIR/associated-types-multiple-types-one-trait.rs:13:5
|
LL | want_y(t);
| ^^^^^^ expected `i32`, found associated type
...
LL | fn want_y<T:Foo<Y=i32>>(t: &T) { }
| ----- required by this bound in `want_y`
|
= note: expected type `i32`
found associated type `<T as Foo>::Y`
help: consider constraining the associated type `<T as Foo>::Y` to `i32`
|
LL | fn have_x_want_y<T:Foo<X=u32, Y = i32>>(t: &T)
| ^^^^^^^^^
```
```
error[E0308]: mismatched types
--> $DIR/trait-with-missing-associated-type-restriction.rs:12:9
|
LL | qux(x.func())
| ^^^^^^^^ expected `usize`, found associated type
|
= note: expected type `usize`
found associated type `<impl Trait as Trait>::A`
help: consider constraining the associated type `<impl Trait as Trait>::A` to `usize`
|
LL | fn foo(x: impl Trait<A = usize>) {
| ^^^^^^^^^^
```
|
|
Implement RFC 2396: `#[target_feature]` 1.1
Tracking issue: #69098
r? @nikomatsakis
cc @gnzlbg @joshtriplett
|
|
fix rustdoc warnings
|
|
cleanup: `config::CrateType` -> `CrateType`
|
|
Mark query function as must_use.
And use the `ensure()` version when the result is not needed.
|
|
Implement RFC 2396: `#[target_feature]` 1.1
Tracking issue: #69098
r? @nikomatsakis
cc @gnzlbg @joshtriplett
|
|
|
|
We anticipate this to have uses in all sorts of crates and keeping it in
`rustc_data_structures` enables access to it from more locations without
necessarily pulling in the large `librustc` crate.
|
|
|
|
remove AllocId generalization of Pointer
This was only needed for the "snapshot" machinery, which is gone.
r? @oli-obk
|
|
Miri: port error backtraces to std::backtrace
No need to pull in an external dependency if libstd already includes this feature (using the same dependency internally, but... still).
r? @oli-obk
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #71018 (handle ConstValue::ByRef in relate)
- #71758 (Remove leftover chalk types)
- #71760 (Document unsafety for `*const T` and `*mut T`)
- #71761 (doc: reference does not exist, probably a typo)
- #71762 (doc: this resulted in a link pointing to a non-existent target)
Failed merges:
- #71726 (Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability)
r? @ghost
|
|
Remove leftover chalk types
Split out from #69406
Since the other PR is having memory problems with `parallel-compiler = true`, figured I should split this out. Surprisingly, this actually changes some errors, and I'm not quite sure why.
r? @nikomatsakis
|
|
handle ConstValue::ByRef in relate
fixes #68615
r? @eddyb
|
|
Avoid duplicating code for each query
There are at the moment roughly 170 queries in librustc.
The way `ty::query` is structured, a lot of code is duplicated for each query.
I suspect this to be responsible for a part of librustc'c compile time.
The first part of this PR reduces the amount of code generic on the query,
replacing it by code generic on the key-value types. I can split it out if needed.
In a second part, the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits
are made into a virtual dispatch table. This allows to reduce even more the number of generated
functions.
This allows to save 1.5s on check build, and 10% on the size of the librustc.rlib.
(Attributed roughly half and half).
My computer is not good enough to measure properly compiling time.
I have no idea of the effect on performance. A perf run may be required.
cc #65031
|
|
|
|
|
|
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
|
|
pointers
|
|
|
|
|
|
|