Refactor ExtInfo to use the builder pattern for construction.

[varungandhi-apple]

• We could probably reduce some of the duplication with more helper methods that call intoBuilder() and build().
• I don't feel particularly strongly about the method names.
• git-clang-format had a bit of a field day with reformatting the surrounding code, so that's a bit unfortunate...
• The first commit in present in a separate PR. [NFC] Rename ExtInfo::Uncommon to ExtInfo::ClangTypeInfo. #33117
• The non-introduction of invariant checking is deliberate. I imagine something or the other is going to blow up when we introduce more checks, so we can do that one-by-one and refactor small amounts of code, instead of introducing the invariant checks and doing the refactoring in this PR (which is already somewhat big).

[varungandhi-apple]

Forum discussion thread: https://forums.swift.org/t/refactoring-extinfo-to-use-a-builder-style-api-to-enforce-correctness-by-construction/38726

[varungandhi-apple]

Marked a bunch of things constexpr.

@swift-ci please smoke test

[varungandhi-apple]

@CodaFi any pending concerns/LGTY?

[davezarzycki]

Hi @varungandhi-apple – Thanks for doing this. Why were a bunch of methods made constexpr? That keyword isn't "free" as far as compile times go so unless you actually need constant evaluation then inline is a better compiler hint. Did you mean to add inline?

[varungandhi-apple]

I don't follow why it should cause additional compile times unless we actually use the constexpr function for compile-time evaluation... maybe I'm missing a piece of the puzzle here. Could you explain your line of reasoning?

[davezarzycki]

You might want to double check with your colleagues at Apple, but I think I remember one of them pointing out that constexpr forces clang to interpret the code before lowering to LLVM IR. For most code, this interpretation adds little to no gains over what the LLVM optimizer can provide but layers of constexpr function calls can cause quite a bit of needless work inside of clang. So unless one actually need to use a function in a constant context (like the size of an array, bitfield sizing, enum constants, etc), then one should either use inline or trust the auto-inliner to do the right thing.

[CodaFi]

Constant-folding at IR-generation time can take care of a lot of this, certainly. But there aren't really wild layers of constexpr here. If Clang cannot handle a chain of bitwise constant evaluations without ballooning build-time performance, we need to file defect reports immediately.

[davezarzycki]

I agree that these specific cases should be harmless.

I think the point this colleague was trying to make was educational: one should prefer inline over constexpr unless you NEED constexpr semantics because of aggregate compounding effects if a code base starts using constexpr all over the place.