Fix const array index limit calculation.

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
#3169 and this all goes away.

Author: jld

src/librustc/middle/trans/consts.rs

@@ -254,7 +254,7 @@ pub fn const_expr(cx: @crate_ctxt, e: @ast::expr) -> ValueRef {
                                         ~"index is not an integer-constant \
                                           expression")
               };
-              let (arr, _len) = match ty::get(bt).sty {
+              let (arr, len) = match ty::get(bt).sty {
                   ty::ty_evec(_, vstore) | ty::ty_estr(vstore) =>
                       match vstore {
                       ty::vstore_fixed(u) =>
@@ -278,36 +278,7 @@ pub fn const_expr(cx: @crate_ctxt, e: @ast::expr) -> ValueRef {
                                            a vector or string type")
               };
 
-              // FIXME #3169: This is a little odd but it arises due to a
-              // weird wrinkle in LLVM: it doesn't appear willing to let us
-              // call LLVMConstIntGetZExtValue on the size element of the
-              // slice, or seemingly any integer-const involving a sizeof()
-              // call. Despite that being "a const", it's not the kind of
-              // const you can ask for the integer-value of, evidently. This
-              // might be an LLVM bug, not sure. In any case, to work around
-              // this we obtain the initializer and count how many elements it
-              // has, ignoring the length we pulled out of the slice. (Note
-              // that the initializer might be a struct rather than an array,
-              // if enums are involved.) This only works because we picked out
-              // the original globalvar via const_deref and so can recover the
-              // array-size of the underlying array (or the element count of
-              // the underlying struct), and all this will hold together
-              // exactly as long as we _don't_ support const sub-slices (that
-              // is, slices that represent something other than a whole
-              // array).  At that point we'll have more and uglier work to do
-              // here, but for now this should work.
-              //
-              // In the future, what we should be doing here is the
-              // moral equivalent of:
-              //
-              // let len = llvm::LLVMConstIntGetZExtValue(len) as u64;
-              //
-              // but we might have to do substantially more magic to
-              // make it work. Or figure out what is causing LLVM to
-              // not want to consider sizeof() a constant expression
-              // we can get the value (as a number) out of.
-
-              let len = llvm::LLVMGetNumOperands(arr) as u64;
+              let len = llvm::LLVMConstIntGetZExtValue(len) as u64;
               let len = match ty::get(bt).sty {
                   ty::ty_estr(*) => {assert len > 0; len - 1},
                   _ => len