[cfe-dev] [RFC] Handling implementation limits

[John McCall via cfe-dev]

On 2 Jan 2020, at 14:58, Mark de Wever wrote:
> On Wed, Jan 01, 2020 at 11:14:16PM -0500, John McCall wrote:
>> On 1 Jan 2020, at 11:16, Mark de Wever wrote:
>>> 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.)
>
> Agreed I should have used the word diagnostic instead. If the limit is
> exceeded it will give an error.
>
>>> The compiler has several limitations often 'hidden' as the width of a
>>> bit-field in a structure. This makes it hard to find these limits. Not
>>> only for our users but also for developers. While looking at a proper
>>> limit for the maximum width of a bit-field in the frontend I discovered
>>> it didn't matter what the frontend picked, the backend already had a
>>> limit [D71142]. To fix this issue the frontend and backend should have
>>> the same limit. To avoid duplicating the value it should be in a header
>>> available to the frontend and backend.
>>
>> FWIW, we don’t generally refer to IRGen as the “backend”.
>>
>> In many cases, the right code change will probably be to introduce a
>> static assertion linking the implementation limit to some value in code,
>> rather than using the limit directly.  For example, many limits will
>> be absolute numbers, and it is probably better to
>> `static_assert(IQ_MaxWidgets < (1ULL << SomeBitFieldWidth))` than to
>> try to make that bit-field have the exact right width.  This is also
>> a pattern that works even if the limit is stored in a normal field
>> of type (say) `unsigned`; such places should also have a `static_assert`
>> in order to remind the reader/maintainer that there’s an implementation
>> limit affected.
>
> If the field SomeBitField is limited by a bit-field width it will also
> create the constant SomeBitFieldMax which contains the maximum value. So
> that would make it easier to directly use the maximum.

You could do that unconditionally by just defining a width that’s wide
enough to store any value up to the limit.

John.