[cfe-dev] [RFC] Handling implementation limits

[Mark de Wever via cfe-dev]

> On Thu, Jan 02, 2020 at 06:23:32PM +0000, Finkel, Hal J. via cfe-dev wrote:
> > On 1/2/20 10:40 AM, Keane, Erich via cfe-dev wrote:
> > While I definitely want us to try to document our implimits, I WILL
> > say that we want to make sure we’re not publishing inaccurate
> > numbers.  Some of the limits are much harder than just testing.  For
> > example, template depth CAN be limited by -ftemplate-depth, however
> > we end up running out of stack space or memory with some fairly
> > simple templates that way even before 1024.
> 
> > If we publish these, I’d be wary that it would become expected that
> > we could do template depth of 1024 (rather than that being a
> > theoretical limit).
> 
> I agree with this, but I also feel like this is not a huge problem in
> practice. Everything that the compiler does is subject to the
> availability of resources (and other permissions/capabilities). These
> limits being discussed impose additional restrictions, and so limit
> the capabilities of the compiler even if resources are available, and
> so long as we provide the general disclaimer, I think that we can
> proceed without considering resource constraints specifically.

I think it's a good idea to add a general disclaimer that these limits
are the limits of the compiler.

We should indeed only document limits that are accurate. In some cases
these limits are not yet known to us. That isn't ideal, but in some
cases it will be the truth. Hopefully over time we can fill in these
blanks.

> > One other concern I have is a more specific one, BitFieldBits, which
> > limits the size by setting a bitfield size itself (in
> > CGRecordLayout). The current size is chosen in a way that seems to
> > intentionally make a size of CGBitFieldInfo not have padding.  Any
> > time we create one of these we need to make sure that we document
> > the reason for the size, so that we have an understanding of why it
> > was set that size.
> 
> > Finally, I believe we should diagnose on all of the implimits that
> > we come across as well.  BitFieldBits is very important one to do
> > semantic analysis diagnosis on, particularly if we’re going to
> > document it.

> As far as rationale documentation goes, however, it would certainly
> make sense to note which limits are "practically unlimited", in the
> sense that you're likely to run out of resources far before you hit
> that particular threshold.

I like the suggestion to add a rationale to why a limit was chosen. I'm
not sure we can determine all of our historical choices, but it would be
good to add them for future choices. (I indeed suspect using the number
of available bits to fill a bit-field to x bytes is often used as
rationale.)

We indeed should diagnose these limits, that's one of the reasons to
look into this task. I noticed several limits being diagnosed by an
assertion, which is less than ideal.

-Mark