r272247 - [Sema] Don't crash when a field w/ a mem-initializer clashes with a record name
David Majnemer via cfe-commits
cfe-commits at lists.llvm.org
Thu Jun 9 07:51:08 PDT 2016
It would mean that the instantiation of the class template gained a field
which should be impossible.
On Thursday, June 9, 2016, Kim Gräsman <kim.grasman at gmail.com> wrote:
> On Thu, Jun 9, 2016 at 7:26 AM, David Majnemer via cfe-commits
> <cfe-commits at lists.llvm.org <javascript:;>> wrote:
> > Author: majnemer
> > Date: Thu Jun 9 00:26:56 2016
> > New Revision: 272247
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=272247&view=rev
> > Log:
> > [Sema] Don't crash when a field w/ a mem-initializer clashes with a
> record name
> >
> > It is possible for a field and a class to have the same name. In such
> > cases, performing lookup for the field might return a result set with
> > more than one entry. An overzealous assertion fired, causing us to
> > crash instead of using the non-class lookup result.
> >
> > This fixes PR28060.
> >
> > Modified:
> > cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> > cfe/trunk/test/SemaCXX/member-init.cpp
> >
> > Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp?rev=272247&r1=272246&r2=272247&view=diff
> >
> ==============================================================================
> > --- cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp Thu Jun 9 00:26:56
> 2016
> > @@ -2637,8 +2637,7 @@ Sema::InstantiateClassMembers(SourceLoca
> > Instantiation->getTemplateInstantiationPattern();
> > DeclContext::lookup_result Lookup =
> > ClassPattern->lookup(Field->getDeclName());
> > - assert(Lookup.size() == 1);
> > - FieldDecl *Pattern = cast<FieldDecl>(Lookup[0]);
> > + FieldDecl *Pattern = cast<FieldDecl>(Lookup.front());
> > InstantiateInClassInitializer(PointOfInstantiation, Field,
> Pattern,
> > TemplateArgs);
> > }
>
> Now what if there is no match? Or is that guaranteed (given the prior
> assert)?
>
> - Kim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160609/0d762ca7/attachment-0001.html>
More information about the cfe-commits
mailing list