[cfe-dev] [RFC] Handling implementation limits

[Bruno Ricci via cfe-dev]

On 02/01/2020 04:14, John McCall wrote:
> On 1 Jan 2020, at 11:16, Mark de Wever wrote:
> 
>     This RFC asks the community for its interest in centralizing Clang's
>     implementation limits and how you feel about the proposed approach.
> 
>     Abstract
>     ========
> 
>     At the moment the implementation limits of the Clang compiler are hidden
>     in magic numbers in the code. These numbers sometimes differ between the
>     frontend and the backend. They are not always properly guarded by compiler
>     warnings, instead they trigger assertion failures.
> 
> /Technically/, crashing is still a valid way of indicating non-acceptance,
> although obviously I agree that we should diagnose these things properly.
> (They can’t just be warnings, though.)
> 
>     This proposal suggests a TableGen based solution to better maintain these
>     limits. This solution will be able to generate a header and documentation
>     of these limits. The latter is required by the C++ standard [implimits].
> 
> I think this is a great approach.

Strong +1 here. I agree that all of these limits should be centralized somewhere
and documented for end-users. MSVC has a nice page with some of the limits
(https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2019). As a bonus
it will also help with fuzzing.

> 
>     The problem
>     ===========
> 
>     The proposal tries to solve 2 issues:
>     * Implementation limits are not always clear and duplicated in the source.
>     * Document C++ Implementation quantities is required by the C++ standard
>     [implimits].
> 
> I suspect that the biggest part of this project by far will be testing
> these implementation limits and then figuring out all the places that they
> fall over.

I think that it would make sense to group all of these tests in a new sub-folder,
say "tests/Implimits" for example, because they are not specific to Sema or the parser
but actually test that a given limit is supported end-to-end.

Bruno