[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