Adds (De)Serialization of Declaration Bounds

[lenary]

This pull request comprehensively revisits and expands the PCH tests, and adds (de)serialization of the bounds associated with global variables, function returns, and struct member fields.

The only way at the moment to test that bounds declarations on global fields and functions are preserved is to redeclare the same function, which should error if you drop the bounds, and not error if you preserve the right bounds as in the precompiled header.

Bounds expressions on struct members are very hard to test, until we start inferring and solving bounds information. The test for itype() should work today, the others will become useful later.

As for serialization/deserialization. I've added the code to do so to the VisitDeclaratorDecl methods, because the bounds information is stored within that class (as opposed to its subclasses). Doing this alone caused an assertion failure in the bitcode writer, namely "Invalid abbrev for record!", file ../llvm/include/llvm/Bitcode/BitstreamWriter.h, line 268. (If this happens again, I hope searching turns up this ticket). I believe I have added the correct entries to the abbreviation system. The clang regression tests pass on 32-bit, I'm currently running them on 64-bit.

Closes #104.

Relevant to #105 and #106 but I think the tests need more work before I can close those two.

[msftclas]

Hi @lenary, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Samuel Hemsley Elliott). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[lenary]

Clang regression tests pass on 64-bit Windows.

[dtarditi]

One small typo; the comment should be hasBoundsExpr.

[lenary]

Every time I look at theAbv lines, I become less convinced I know what's going on with them. I'm going to review this file again, and run a lot of clang tests.

My concern is that these seem to be defining a layout. In this line, I'm saying "there's a fixed-width field here, 1 bit wide, that says whether we have a bounds expression", I think. This is correct only when hasBoundsExpr() is false. If we have a bounds expression, we have the field for hasBoundsExpr() followed immediately by a field containing the bounds expression in purpose, showing this is not fixed width.

I think I have a more robust fix incoming, which we can always revisit later.

[lenary]

Ok, my tests pass. What 9d4e5be does is disable the use of abbreviations if we have a bounds expression, meaning the abbreviations are always correct. This is alright for the moment, but may in future be something we want to optimize.

[dtarditi]

Yes, I agree that we should turn off the use of abbreviations when bounds declarations are present for declarations.