[PATCH] D19754: Allow 'nodebug' on local variables

[Robinson, Paul via cfe-commits]

This would be a great conversation to have at the social, sadly I will
have to miss it this month.

>> dblaikie wrote:
>>> Doesn't look like the const case is any different from the non-const
>>> case, is it?
>> Given a white-box analysis of the compiler internals, you are correct;
>> this is in contrast to the static const/non-const handling, which *does*
>> use different paths.
>> I am unwilling to trust that the const/non-const paths for locals will
>> forever use the same path.  You could also look at it as "the test is
>> the spec."
>
> But even then - what about any other property of a variable? What if it's
> in a nested scope instead of a top level scope? What if it's declared in
> a condition (if (int x = ...)). What if it's volatile? We could pick
> arbitrary properties that /could/ have an effect on debug info but we
> generally believe to be orthogonal to the feature at hand

What you are describing is what testing literature refers to as criteria
for equivalence classes.  There is some level of judgment to that, yes.

> & I'd say 'const' is in the same group of things.

I would have thought exactly that for the static-storage case, but it is
demonstrably not true.  Therefore, const/not is a valid distinction for
the equivalence classes in the static case.  Needing a separate const
test for the static case, it seems completely appropriate to have the 
same for the auto case.  In other words, in my judgment the storage-class
doesn't seem relevant to the equivalence class criteria for the test.

> (a const local variable still needs storage, etc, - the address can be
> escaped and accessed from elsewhere and determined to be unique

All of those objections apply equally to the static case, and yet the
static case must have separate tests.

> - and both variables in this example could be optimized away entirely
> by the compiler because they're unused, so the const is no worse off
> there in that theoretical concern)

Again not different for the (file-)static case.  If a file-static
variable is not used in the CU there's no reason for it to be emitted.
As it happens I *did* need uses to get the static cases to work, and
(currently) don't need uses to get the local cases to work, so in the
interest of not including elements in the test case that are irrelevant
to the feature-under-test, I didn't add uses of the locals.

This is an argument for doing the test exactly as I did: first run it
to prove debug info IS emitted in the absence of the attribute, then
again to prove debug info is suppressed in the presence of the attribute.
That way if optimization or lack-of-use means the variable is not emitted,
the test can be adjusted to make sure that condition does not apply,
proving that the lack of debug info is properly because of the attribute
and not because of some other irrelevant circumstance.

--paulr