rust-lang / ena

An implementation of union-find / congruence-closure in Rust. Extracted from rustc for independent experimentation.

An implementation of union-find in Rust; extracted from (and used by) rustc.

Name

The name "ena" comes from the Greek word for "one".

Features

By default, you just get the union-find implementation. You can also opt-in to the following experimental features:

• bench: use to run benchmarks (cargo bench --features bench)

License

Like rustc itself, this code is dual-licensed under the MIT and Apache licenses. Pull requests, comments, and other contributions are assumed to imply consent to those terms. Moreover, it is understood that any changes here may well be used in rustc itself under the same terms.

ena's Issues

Delete key operation?

Hi,

I am writing a wasm type checker in Rust, and I am using ena to help with operand unification problems arising during the validation of instruction sequences. Some wasm instructions can bind parametric arguments and I thought it would be much easier to use ena for unifying type parameters than implementing a hand coded solution. This requires me to create a single unification table for the whole instruction sequence, and in a forward chaining manner add a new key for each parameter encountered, possibly unifying some of the existing ones.
Of course the issue is that the UnificationTable just grows and grows while I am munching the sequence, while I only need the keys that are on the operand stack.

So I would need a way to delete keys from the UnificationTable for the symbols that are popped from the stack. This shouldn't affect the merged values, the table should forget about the key, not undo a merge (like reverting snapshots). Of course when the last member of the group is gone, the value should be dropped too.

Is this something that should be worth implementing, or is there a way to do this already and I just overlooked it?

Documentation of `order_roots` is outdated

https://docs.rs/ena/0.14.0/ena/unify/trait.UnifyKey.html#method.order_roots
seems to believe that its output is a boolean, when that is not the case

evaluate perf shifts caused by adopting ena in rustc

In rust-lang/rust#47861, @sgrif recently switched rustc to use ena. This caused a huge perf regression, but for reasons unrelated to ena -- it was followed up by rust-lang/rust#48666 which reverted the troublesome commit. Still, looking at the combined scores here shows a small (but measurable) regression of a few percent on certain tests:

perf comparison showing combined results of 47861 and 48666

It's a bit messy because that diff includes some other commits. These are the perf results we did before landing, in which that troublesome commit was excluded:

perf comparison from before landing

You can see that the changes there are all in the 1-3% range. Some things worth investigating:

• Was the 11% clap-rs regression caused by these PRs or not? It wasn't measured before landing
• In order to make things faster, we also removed congruence closure from ena before landing. However, that didn't seem to make as much affect as I was hoping. Was it necessary?
• Are there improvements we can make to ease the smaller regressions?

On the last point: there were a few distinct steps that we changed in rustc in the course of adopting ena. For example, we moved the types into the unification table directly. It might be that this caused a slight shift in cache misses or other things. Worth evaluating. I was wondering if [reodering the fields in the VarValue struct might be a win]:

https://github.com/rust-lang-nursery/ena/blob/7768e8f2f3d942580c7d3cb62d267af487e67865/src/unify/mod.rs#L158-L161

Or potentially separating the value field into a separate vector.

bitvec.rs is unused

I was looking at the code and it looks like bitvec.rs is unused. Should it just be removed?

`UnificationTable::probe_value` unnecessarily requires UnificationStoreMut

The methods probe_value and find can be moved to a separate impl that doesn't require UnificationStoreMut bound.

Possibility of no-std support

I am contemplating removing the home-grown UnionFind structure of petgraph with ena.

We'd like to be able to provide petgraph in no-std; therefore: is there a possibility of ena being available as a no-std (but alloc) library?

UnifyValue cannot contain UnifyKey

Hi, I am using ena for type inference in my programming language:

pub type Context = UnificationTable<InPlace<TypeVar>>;
impl UnifyKey for TypeVar { ... }
impl UnifyValue for Type { 
    fn unify_values(a: &Self, b: &Self) -> Result<Self, (Self, Self)> {
        ...
    }
 }
struct TypeVar(u32);

I am however struggling to unify compound types. It seems to me like I will run into problems if aType (UnifyValue) contains a TypeVar (UnifyKey), for example:

enum Type {
    Int,
    Fun {
        input: Vec<TypeVar>,
        output: TypeVar
    },
    Unknown
}

The problem is I cannot unify two variables (unify_var_var) within the unify_values function since I don't have access to the UnificationTable. Everything works if I instead represent it as:

enum Type {
    Int,
    Fun {
        input: Vec<Type>,
        output: Box<Type>
    },
    Unknown
}

But I feel like there is a better approach, do you have any advice? Otherwise, is it possible to extend ena so it can unify variables within the unify_var_var function?

Implement Debug for UnificationTable

I am developing my own programming language and I am having trouble figuring out what is happening with my type inference.

I would love if I could debug print UnificationTable to figure out what's going in it.

API questions / problems

Hi, I'm using ena for type inference it works excellently but I got some questions:

• After type inference, using the UnificationTable as a side-table for looking up type information is cumbersome since probe_value takes &mut self, does it need to?

• Maybe it would be better if I convert the UnificationTable into a Vec<Value> indexed by Key, or HashMap<Key, Value>. In this case, it would be useful to know the number of roots in the UnificationTable so I can pre-allocate the capacity, but I could not find a method for it. Would it make sense to add this or not?

• Would you recommend storing type information this way, or is it better to store it directly in AST nodes?

Move Repository To rust-lang

Hello, the current rust-lang-nursery organisation is considered deprecated, and the Rust Programming Language organisation is trying to consolidate managing Rust's GitHub organisations, as such we'd like you to consider moving your repository to the main rust-lang organisation instead.

How Do I Move To rust-lang?

You most likely won't be able to transfer your repository directly, if so you'll need to transfer your repository to @Mark-Simulacrum, who will then move your repository to the rust-lang organisation.

Deprecating

If you no longer intend to maintain this repository, please let us know and we will take of deprecating the project.

UnifyValues and UnificationTable

I am trying to implement algorithm w based on the wikipedia description.
As far as I understand I should be unifying monotypes, so I created key type that implements UnifyKey with my monotype enum as associated value.

Then I tried to implement UnifyValue for the monotype. This seems to be impossible, as for the type constructors I need to recursively unify each parameter, which I can't do as unify_values doesn't take UnificationTable as parameter.

Am I missing something or is this deficiency in the library?

Bounds on `Delegate<K>` which is `#[doc(hidden)]`

This type is very visible in the various bounds, but because the item itself is hidden, this provides a very confusing and irritating experience when the compiler emits errors about the hidden type. One cannot simply reference its rustdoc page, for instance.