[cfe-commits] [PATCH review request] unused overloaded expression should error

Douglas Gregor dgregor at apple.com
Tue Feb 22 16:49:20 PST 2011


On Feb 21, 2011, at 7:54 PM, Faisal Vali wrote:

> Oops - sorry Doug - I made the relevant changes - I should have known
> to perform those stylistic tweaks upfront - will try and be better
> about that.

No problem.

> I also moved the check after the DiagnoseUnexpandedParameterPack - but
> can i ask why - what scenario did you have in mind?

Say 'Types' is a template parameter pack. I was concerned that

  foo<Types>;

would do something stupid in ResolveSingleFunctionTemplateSpecialization.

Do you have test cases to add to the patch?

  - Doug

> Thanks!
> Faisal Vali
> 
> 
> 
> 
> 
> On Mon, Feb 21, 2011 at 11:58 AM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> On Feb 20, 2011, at 3:30 PM, Faisal Vali wrote:
>> 
>>> This patch is peripherally related to my previous patch regarding bug 7505.
>>> 
>>> 
>>> I stumbled upon the following test code, that should error, but doesn't.
>>> 
>>> void two() { }
>>> void two(int) { }
>>> 
>>> int main()
>>> {
>>>  two; // clang emits unused variable warning, but this should be an error -
>>> }
>>> 
>>> The attached patch ensures that clang produces an error.
>>> 
>>> Would appreciate any feedback :)
>>> thanks!
>> 
>> A few nits:
>> 
>> +  if (FullExpr->getType() == Context.OverloadTy) {
>> +    if (!ResolveSingleFunctionTemplateSpecialization(FullExpr,
>> +      /* Complain */ false))
>> +    {
>> 
>> Please line up with " /* Complain */false" with "FullExpr", as we usually do in the LLVM/Clang code base.
>> 
>> Also, {'s usually go on the end of the line (rather than on a new line).
>> 
>> Finally, I suggest that this check go after the DiagnoseUnexpandedParameterPack() call.
>> 
>>        - Doug
> <2-address-of-overloaded-function-in-id-expression-stmt.patch>





More information about the cfe-commits mailing list