[cfe-dev] clang::ObjCInterfaceTypeLoc

[Vladimir Voskresensky via cfe-dev]

Hi Alex,


On 02/14/17 04:23 AM, Alex L via cfe-dev wrote:
> Hi Vladimir,
>
> It looks to me that this is a bug. However, it currently seems to 
> works because ObjCInterfaceLocInfo is initialized 
> through ObjCObjectTypeLoc so ObjCObjectTypeLocInfo is valid, and after 
> that we initialize ObjCInterfaceTypeLocInfo.
Are you sure, that this is valid? All *Loc classes memory initialization 
is done through TypeSourceInfo which prepares memory of corresponding 
size for TypeLoc data (clang::ASTContext::CreateTypeSourceInfo).
So for ObjCInterfaceLoc when TypeLoc::getFullDataSizeForType does the 
calculation => LocalData size is sizeof(ObjCInterfaceLocInfo) (counted 
in ConcreteTypeLoc::getLocalDataSize) and ObjCObjectTypeLoc is not asked 
about it's LocalData size => when call methods of ObjCObjectTypeLoc it 
casts TypeLoc::Data to ObjCObjectTypeLocInfowhich was not allocated 
properly (except memory for the 2 first fields which we get from 
ObjCInterfaceLocInfo).


> I guess that we don't really see the effect of the bug because we 
> don't have tests that check for conflict between the name location 
> from ObjCInterfaceTypeLocInfo and left angle/right angle locations 
> from ObjCObjectTypeLoc.
So may be there is no need in inheritance and it should be as simple as.
class ObjCInterfaceTypeLoc : public ConcreteTypeLoc<**UnqualTypeLoc**,
ObjCInterfaceTypeLoc,
ObjCInterfaceType,
ObjCInterfaceLocInfo> {

> I think that it would make sense for ObjCInterfaceTypeLoc to derive 
> from ObjCObjectTypeLoc directly. I'll try to clean it up.
I thought for inheritance you need same-structured LocInfo and use 
InheritingConcreteTypeLoc

Vladimir.

>
> Alex
>
> On 12 February 2017 at 16:34, Vladimir Voskresensky via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     Hello Clang experts,
>
>     Could you help me, please, to understand how does
>     ObjCInterfaceTypeLoc class suppose to work?
>     ObjCInterfaceTypeLoc is the only one class in TypeLoc hierarchy
>     which inherits twice from ConcreteTypeLoc.
>     I see in source code and visually at
>     http://ftp.llvm.org/doxygen/classclang_1_1ObjCInterfaceTypeLoc.html
>     <http://ftp.llvm.org/doxygen/classclang_1_1ObjCInterfaceTypeLoc.html>
>
>     It is derived from ObjCObjectTypeLoc (which uses
>     ObjCObjectTypeLocInfo),
>     but has own ObjCInterfaceLocInfo (passed as LocalData).
>     Does it replace the ObjCObjectTypeLocInfo used by ObjCObjectTypeLoc?
>     ObjCInterfaceLocInfo is not derived from ObjCObjectTypeLocInfo, so
>     sizeof(ObjCInterfaceLocInfo) < sizeof(ObjCObjectTypeLocInfo)
>     How methods of ObjCObjectTypeLoc can work for ObjCInterfaceTypeLoc
>     instance?
>     Shouldn't it be more like:
>     http://clang.llvm.org/doxygen/classclang_1_1TypeofLikeTypeLoc.html
>     <http://clang.llvm.org/doxygen/classclang_1_1TypeofLikeTypeLoc.html>
>
>
>     Thanks!
>     Vladimir.
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170214/24f0caa7/attachment.html>