[PATCH] Was: Re: r178663 - Don't compute a patched/semantic storage class.

[Richard Smith]

On Thu, May 9, 2013 at 12:19 PM, Enea Zaffanella <zaffanella at cs.unipr.it>wrote:

> On 04/03/2013 05:50 PM, Rafael Espindola wrote:
>
>> Author: rafael
>> Date: Wed Apr  3 10:50:00 2013
>> New Revision: 178663
>>
>> URL: http://llvm.org/viewvc/llvm-**project?rev=178663&view=rev<http://llvm.org/viewvc/llvm-project?rev=178663&view=rev>
>> Log:
>> Don't compute a patched/semantic storage class.
>>
>> For variables and functions clang used to store two storage classes. The
>> one
>> "as written" in the code and a patched one, which, for example, propagates
>> static to the following decls.
>>
>> This apparently is from the days clang lacked linkage computation. It is
>> now
>> redundant and this patch removes it.
>>
>
> [...]
>
>  +Storage Class
>> +^^^^^^^^^^^^^
>> +
>> +For each variable and function Clang used to keep the storage class as
>> written
>> +in the source, the linkage and a semantic storage class. This was a bit
>> +redundant and the semantic storage class has been removed. The method
>> +getStorageClass now returns what is written it the source code for that
>> decl.
>>
>
>
> Hello Rafael.
>
> I think we found an occurrence of "patched/semantic storage class" that
> survived your commit. Here is the example showing the problem:
>
> $ cat tl.cc
> void foo() {
>   thread_local int i;
> }
>
> If you pretty print it, you will see the "static" storage class specifier.
>
> Please find attached a patch for review.
> The patch avoids the patched/semantic storage class computation. As a
> necessary consequence, it also adapts the implementation of VarDecl methods
> hasLocalStorage() and isStaticLocal() to also check the thread storage
> specifier.
>
> Cheers,
> Enea.
>
> P.S.: there actually are a couple of other occurrences of
> "patched/semantic storage class", but these are related to OpenCL/CUDA
> extensions and are not addressed in the patch.


We should really rename getStorageClassSpec to
getStorageClassSpecAsWritten, too, to reduce the risk of it accidentally
being used to determine the storage class for a variable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130509/fbebf292/attachment.html>