Fix the block stack used by the bitstream cursor.

include/llvm/Bitcode/NaCl/NaClBitCodes.h

Index: include/llvm/Bitcode/NaCl/NaClBitCodes.h
diff --git a/include/llvm/Bitcode/NaCl/NaClBitCodes.h b/include/llvm/Bitcode/NaCl/NaClBitCodes.h
index 2d6b90e113e3ec430b5d4db038447d33d282fbd4..aba077527c5752a55bf4568a6c92d03cc9e2a921 100644
--- a/include/llvm/Bitcode/NaCl/NaClBitCodes.h
+++ b/include/llvm/Bitcode/NaCl/NaClBitCodes.h
@@ -22,6 +22,7 @@
 #include "llvm/Support/DataTypes.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"
+#include <climits>

[Jim Stichnoth, 2016/03/14 22:46:49]

Should includes be sorted?

[Karl, 2016/03/15 20:29:41]

This code was (originally) copied from LLVM, and it wasn't sorted. From what I
can tell, they don't do this in general.  The goal with these files it to create
a little churn as possible, so that it is easier to incorporate upstream changes
in LLVM.

 #include <cassert>
 
 namespace llvm {
@@ -81,7 +82,11 @@ enum StandardWidths {
     BLOCKINFO_BLOCK_ID = 0,
 
     // Block IDs 1-7 are reserved for future expansion.
-    FIRST_APPLICATION_BLOCKID = 8
+    FIRST_APPLICATION_BLOCKID = 8,
+    // Dummy block added around all records in a bitcode file. Allows the code
+    // to treat top-level records like all other records (i.e. all records
+    // appear in a block).
+    TOP_LEVEL_BLOCKID = UINT_MAX

[Derek Schuff, 2016/03/15 17:47:04]

Does it matter that this block will be considered an application block id by
NaClBitcodeBlockDist.cpp and NaClBitcodeCodeDist.cpp?

[Karl, 2016/03/15 20:29:41]

Yes, you are right. It does raise TOP_LEVEL_BLOCKID to an application block.
Moving this to value 7, assuming we will be less likely to get affected by LLVM
changes.

   };
 
   /// BlockInfoCodes - The blockinfo block contains metadata about user-defined