diff options
| author | Niko Matsakis <niko@alum.mit.edu> | 2017-03-10 13:30:09 -0500 |
|---|---|---|
| committer | Niko Matsakis <niko@alum.mit.edu> | 2017-04-11 20:19:23 -0400 |
| commit | 18ea55fe1636001c4d030911e2c4c165af1cabfc (patch) | |
| tree | 222ca84a78682b5c770a32fb205ff1ce2efb5fd1 /src/rustllvm/RustWrapper.cpp | |
| parent | 4a0a0e949a077a6d83ca152daa404ff47c9c1dcf (diff) | |
| download | rust-18ea55fe1636001c4d030911e2c4c165af1cabfc.tar.gz rust-18ea55fe1636001c4d030911e2c4c165af1cabfc.zip | |
remove bivariance
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.
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
