[cfe-dev] TypeLoc SourceRange for builtin types

[Erik Schmidt via cfe-dev]

Good to know, thanks for clearing this up.


Quoting John McCall <rjmccall at apple.com>:

>> On Sep 28, 2017, at 1:01 AM, Erik Schmidt via cfe-dev  
>> <cfe-dev at lists.llvm.org> 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.