about summary refs log tree commit diff
path: root/src/rustllvm/RustWrapper.cpp
diff options
context:
space:
mode:
authorNiko Matsakis <niko@alum.mit.edu>2017-03-10 13:30:09 -0500
committerNiko Matsakis <niko@alum.mit.edu>2017-04-11 20:19:23 -0400
commit18ea55fe1636001c4d030911e2c4c165af1cabfc (patch)
tree222ca84a78682b5c770a32fb205ff1ce2efb5fd1 /src/rustllvm/RustWrapper.cpp
parent4a0a0e949a077a6d83ca152daa404ff47c9c1dcf (diff)
downloadrust-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