...ear
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
r? @catamorphism
Fixes#3169 and uses that to fix const array indexing, which I broke (in a way that doesn't break tests but will greatly confuse users) while trying to fix const enum vectors.
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
The number of operands of the LLVM node initializing the array
underlying a const vector isn't always the array length -- if the
array is of a sufficiently primitive type and all the elements' values
are known (or something like that), LLVM uses a specialized Constant
subclass that stores the data packed, and thus has no operands. Oops.
But, because llsize_of now gives us a ConstantInt, we can just fix
mozilla/rust#3169 and this all goes away.
This adds a `BaseIter` impl to `PriorityQueue`, `TreeMap`, `LinearMap` and `SmallIntMap`, and introduces a `ReverseIter` trait + implementations for `TreeMap`, `TreeSet` and `SmallIntMap`.
There were a bunch of problems with consts where an enum was contained within some other type (vector, tuple, struct, etc.); some of these would cause LLVM assertion failures, and some would silently read from the wrong address. These changes should fix all of that.
It would be good if someone with access to a win32 host could do the equivalent of `make check-stageN-rpass TESTNAME=enum` on that platform before merging this.
This is wasted space if the const is just an enum, but optimizing that
case without breaking everything else is an issue that can be addressed
separately.
