Derive Hash for ThreadId + better example
Derive `Hash` for `ThreadId` (see comments in #21507). Useful for making maps based on thread, e.g. `HashMap<ThreadId, ?>`. Also update example code for thread IDs to be more useful.
Fix pairs of doubles using an illegal <8 x i8> vector.
Accidentally introduced in #40658 and discovered in some Objective-C bindings (returning `NSPoint`).
Turns out LLVM will widen element types of illegal vectors instead of increasing element count, i.e. it will zero-extend `<8 x i8>` to `<8 x i16>`, interleaving the bytes, instead of using the first 8 of `<16 x i8>`.
Highlight and simplify mismatched types
Shorten mismatched types errors by replacing subtypes that are not
different with `_`, and highlighting only the subtypes that are
different.
Given a file
```rust
struct X<T1, T2> {
x: T1,
y: T2,
}
fn foo() -> X<X<String, String>, String> {
X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
}
fn bar() -> Option<String> {
"".to_string()
}
```
provide the following output
```rust
error[E0308]: mismatched types
--> file.rs:6:5
|
6 | X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer}
|
= note: expected type `X<X<_, std::string::String>, _>`
^^^^^^^^^^^^^^^^^^^ // < highlighted
found type `X<X<_, {integer}>, _>`
^^^^^^^^^ // < highlighted
error[E0308]: mismatched types
--> file.rs:6:5
|
10 | "".to_string()
| ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String`
|
= note: expected type `Option<std::string::String>`
^^^^^^^ ^ // < highlighted
found type `std::string::String`
```
Fix#21025. Re: #40186. Follow up to #39906.
I'm looking to change how this output is accomplished so that it doesn't create list of strings to pass around, but rather add an elided `Ty` placeholder, and use the same string formatting for normal types. I'll be doing that soonish.
r? @nikomatsakis
ICH: Replace old, transitive metadata hashing with direct hashing approach.
This PR replaces the old crate metadata hashing strategy with a new one that directly (but stably) hashes all values we encode into the metadata. Previously we would track what data got accessed during metadata encoding and then hash the input nodes (HIR and upstream metadata) that were transitively reachable from the accessed data. While this strategy was sound, it had two major downsides:
1. It was susceptible to generating false positives, i.e. some input node might have changed without actually affecting the content of the metadata. That metadata entry would still show up as changed.
2. It was susceptible to quadratic blow-up when many metadata nodes shared the same input nodes, which would then get hashed over and over again.
The new method does not have these disadvantages and it's also a first step towards caching more intermediate results in the compiler.
Metadata hashing/cross-crate incremental compilation is still kept behind the `-Zincremental-cc` flag even after this PR. Once the new method has proven itself with more tests, we can remove the flag and enable cross-crate support by default again.
r? @nikomatsakis
cc @rust-lang/compiler
Use proper span for tuple index parsed as float
Fix diagnostic suggestion from:
```rust
help: try parenthesizing the first index
| (1, (2, 3)).((1, (2, 3)).1).1;
```
to the correct:
```rust
help: try parenthesizing the first index
| ((1, (2, 3)).1).1;
```
Fix#41081.
remove unnecessary tasks
Remove various unnecessary tasks. All of these are "always execute" tasks that don't do any writes to tracked state (or else an assert would trigger, anyhow). In some cases, they issue lints or errors, but we''ll deal with that -- and anyway side-effects outside of a task don't cause problems for anything that I can see.
The one non-trivial refactoring here is the borrowck conversion, which adds the requirement to go from a `DefId` to a `BodyId`. I tried to make a useful helper here.
r? @eddyb
cc #40746
cc @cramertj @michaelwoerister
Instead of collecting all potential inputs to some metadata entry and
hashing those, we directly hash the values we are storing in metadata.
This is more accurate and doesn't suffer from quadratic blow-up when
many entries have the same dependencies.
Add contribution instructions to stdlib docs
Generally programming language docs have instructions on how to contribute changes.
I couldn't find any in the rust docs, so I figured I'd add an instructions section, let me know if this belongs somewhere else!
```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
```
Add the RLS as a submodule and build a package out of it
r? @brson (and cc @alexcrichton) Please review closely, I am not at all convinced I've done the right things here. I did run `x.py dist` and it makes an rls package which looks right to my eyes, but I haven't tested on non-linux platforms nor am I really sure what it should look like.
This does not attempt to run tests for the RLS yet.
When we are generalizing a super/sub-type, we have to replace type
variables with a fresh variable (and not just region variables). So if
we know that `Box<?T> <: ?U`, for example, we instantiate `?U` with
`Box<?V>` and then relate `Box<?T>` to `Box<?V>` (and hence require that
`?T <: ?V`).
This change has some complex interactions, however:
First, the occurs check must be updated to detect constraints like `?T
<: ?U` and `?U <: Box<?T>`. If we're not careful, we'll create a
never-ending sequence of new variables. To address this, we add a second
unification set into `type_variables` that tracks type variables related
through **either** equality **or** subtyping, and use that during the
occurs-check.
Second, the "fudge regions if ok" code was expecting no new type
variables to be created. It must be updated to create new type variables
outside of the probe. This is relatively straight-forward under the new
scheme, since type variables are now independent from one another, and
any relations are moderated by pending subtype obliations and so forth.
This part would be tricky to backport though.
cc #18653
cc #40951
In some specific cases, the new scheme was failing to learn as much from
a LUB/GLB operaiton as the old code, which caused coercion to go awry. A
slight ordering hack fixes this.
In some cases, we give multiple primary spans, in which case we would
report one `//~` annotation per primary span. That was very confusing
because these things are reported to the user as a single error.
UI tests would be better here.
There is one fishy part of these changes: when computing the LUB/GLB of
a "bivariant" type parameter, I currently return the `a`
value. Bivariant type parameters are only allowed in a very particular
situation, where the type parameter is only used as an associated type
output, like this:
```rust
pub struct Foo<A, B>
where A: Fn() -> B
{
data: A
}
```
In principle, if one had `T=Foo<A, &'a u32>` and `U=Foo<A, &'b u32>`
and (e.g.) `A: for<'a> Fn() -> &'a u32`, then I think that computing the
LUB of `T` and `U` might do the wrong thing. Probably the right behavior
is just to create a fresh type variable. However, that particular
example would not compile (because the where-clause is illegal; `'a`
does not appear in any input type). I was not able to make an example
that *would* compile and demonstrate this shortcoming, and handling the
LUB/GLB was mildly inconvenient, so I left it as is. I am considering
whether to revisit this.
