[RFC] An opt-in CMake option for 64-bit Source Location

[rnk]

We discussed this RFC in the area team meeting, and based on the comments here, and some context from the notes from the last call dedicated to this RFC, here’s where we think things stand:

1. Most stakeholders don’t want to take the peak memory usage regression.
2. Some stakeholders are worried about maintenance costs from implied guarantees of support. Adding a build mode implies the configuration is supported, and that it should be included in the set of configurations we build and test, and the community doesn’t want to bear that cost.
3. @vvassilev is working on a project proposal for reusing source locations for textual headers in different modules. This would mitigate source location exhaustion for modules and keep memory usage low, but it requires significant effort and marginally degrades diagnostic quality. If someone steps up to implement this, that would probably be our preferred outcome, assuming the diagnostic quality tradeoff isn’t too bad.
4. Finally, we’d be willing to reconsider going forward with the build mode for 64-bit source locations if another downstream stakeholder came forward and requested this mode. We have two stakeholders (Intel, Google) who need this mode, but we feel on balance the other interests outweigh these interests, and having more users could swing the tradeoff back in favor of the proposal.

That’s a recap of what we discussed, and I look forward to more details on the open project from @vvassilev , and I think we can formally say we’re not going forward with the original proposal.

---

Beyond what we discussed in the Clang ATL meeting, I can share my own thoughts.

@hokein

Proceed with the infrastructure changes to the SourceLocation data structure to support 64 bits, but keep the actual effective size set to 32 bits by default via a constant

@Endill

From your description is seems that ensuring the working state of 64-bit infrastructure will be done by downstreams who would actually switch to 64-bit via the one-liner you have in mind. This would go against our typical approach of having CI for things we support, and can lead to uptick in reverts, when downstreams report that a new change has broken this infrastructure.

I don’t think it would be reasonable for downstreams to revert changes based on the implication that Clang supports 64-bit slocs. What I expect to happen here is that downstreams using 64-bit slocs are likely to encounter memory usage regressions from bad struct packing, and that is squarely their problem to figure out. I think opting into 64-bit slocs is basically a choice by a downstream that they would rather take on the maintenance burden of keeping 64-bit slocs working on their own than bear the support burden of dealing with customers with modules full of large, textual headers, and that’s their prerogative.

Given the amount of time that @hokein has put into this project thus far and speaking as someone who would be on the hook to bear the maintenance burden of this local patch for Google, you can draw your own conclusions about which option we think has lower maintenance cost.