TypeLoc SourceRange for builtin types

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TypeLoc SourceRange for builtin types

David Chisnall via cfe-dev
Greetings,

  for getting the written source of the type of a field, I'm using


  pFieldDecl->getTypeSourceInfo()->getTypeLoc().getSourceRange();


  This works great, it returns "int" for a field like "int foo;" or  
even "vector<int>" for a field like "vector<int> bar;", as expected.  
However, for built-in types with a space inside, like "unsigned int"  
or "signed char", this doesn't work, strangely. For example, for a  
field like this:

  signed char foo;

  the source range returned only contains the first word, namely  
"signed". But it should contain "signed char", shouldn't it?

  It's the same for all built-in type combinations and happens  
everywhere, at parameters, return types of functions and others. Am I  
misunderstanding something here? Can't imagine that this is a bug,  
since everything else works so nicely. Any hint of what I am doing  
wrong?


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: TypeLoc SourceRange for builtin types

David Chisnall via cfe-dev
> On Sep 28, 2017, at 1:01 AM, Erik Schmidt via cfe-dev <[hidden email]> wrote:
> Greetings,
>
> for getting the written source of the type of a field, I'm using
>
>
> pFieldDecl->getTypeSourceInfo()->getTypeLoc().getSourceRange();
>
>
> This works great, it returns "int" for a field like "int foo;" or even "vector<int>" for a field like "vector<int> bar;", as expected. However, for built-in types with a space inside, like "unsigned int" or "signed char", this doesn't work, strangely. For example, for a field like this:
>
> signed char foo;
>
> the source range returned only contains the first word, namely "signed". But it should contain "signed char", shouldn't it?
>
> It's the same for all built-in type combinations and happens everywhere, at parameters, return types of functions and others. Am I misunderstanding something here? Can't imagine that this is a bug, since everything else works so nicely. Any hint of what I am doing wrong?

We don't currently keep absolutely all of the source information in the TypeLoc.  For example, we only store a single location in BuiltinTypeLoc.  Another example is that we don't store location information for basic CVR qualifiers.  I think that it's quite arguable that we should do these things, but it's not a simple matter because we'd want to ensure that we didn't waste a ton of memory doing things like, say, storing an empty SourceLocation for a volatile qualifier that isn't there.  And there are aspects of the current TypeLoc / TypeSourceInfo design that we'd need to reconsider in order to really do that well, like the fact that the buffer size of a TypeLoc can be determined entirely from the QualType.  Still, if someone were interested in addressing these problems, I think patches would be welcome.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: TypeLoc SourceRange for builtin types

David Chisnall via cfe-dev
Good to know, thanks for clearing this up.


Quoting John McCall <[hidden email]>:

>> On Sep 28, 2017, at 1:01 AM, Erik Schmidt via cfe-dev  
>> <[hidden email]> wrote:
>> Greetings,
>>
>> for getting the written source of the type of a field, I'm using
>>
>>
>> pFieldDecl->getTypeSourceInfo()->getTypeLoc().getSourceRange();
>>
>>
>> This works great, it returns "int" for a field like "int foo;" or  
>> even "vector<int>" for a field like "vector<int> bar;", as  
>> expected. However, for built-in types with a space inside, like  
>> "unsigned int" or "signed char", this doesn't work, strangely. For  
>> example, for a field like this:
>>
>> signed char foo;
>>
>> the source range returned only contains the first word, namely  
>> "signed". But it should contain "signed char", shouldn't it?
>>
>> It's the same for all built-in type combinations and happens  
>> everywhere, at parameters, return types of functions and others. Am  
>> I misunderstanding something here? Can't imagine that this is a  
>> bug, since everything else works so nicely. Any hint of what I am  
>> doing wrong?
>
> We don't currently keep absolutely all of the source information in  
> the TypeLoc.  For example, we only store a single location in  
> BuiltinTypeLoc.  Another example is that we don't store location  
> information for basic CVR qualifiers.  I think that it's quite  
> arguable that we should do these things, but it's not a simple  
> matter because we'd want to ensure that we didn't waste a ton of  
> memory doing things like, say, storing an empty SourceLocation for a  
> volatile qualifier that isn't there.  And there are aspects of the  
> current TypeLoc / TypeSourceInfo design that we'd need to reconsider  
> in order to really do that well, like the fact that the buffer size  
> of a TypeLoc can be determined entirely from the QualType.  Still,  
> if someone were interested in addressing these problems, I think  
> patches would be welcome.
>
> John.



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev