Page MenuHomePhabricator

[ASTImporter] Fix redecl failures of ClassTemplateSpec

Authored by martong on Feb 26 2019, 6:16 AM.



Redecl chains of class template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.

Diff Detail

Event Timeline

martong created this revision.Feb 26 2019, 6:16 AM
a_sidorin accepted this revision.Mar 3 2019, 11:00 AM

Hi Gabor,
Thanks for the patch! It looks good to me except some stylish nits.


Could you please also replace "those those" to "those" in the comment below?


The comment is a bit broken.

This revision is now accepted and ready to land.Mar 3 2019, 11:00 AM
martong updated this revision to Diff 189131.Mar 4 2019, 3:37 AM
martong marked 2 inline comments as done.
  • Fix some comments

Alexei, thanks for the review!

shafik added inline comments.Mar 5 2019, 1:13 PM

ODR violations are ill-formed no diagnostic required. So currently will this fail for cases that clang proper would not?

martong marked 2 inline comments as done.Mar 7 2019, 5:19 AM
martong added inline comments.

ODR violations are ill-formed no diagnostic required.

ASTStructuralEquivalenceContext already provides diagnostic in the ODR cases. E.g.:

// Check for equivalent field names.
IdentifierInfo *Name1 = Field1->getIdentifier();
IdentifierInfo *Name2 = Field2->getIdentifier();
if (!::IsStructurallyEquivalent(Name1, Name2)) {
  if (Context.Complain) {
                      ? diag::err_odr_tag_type_inconsistent
                      : diag::warn_odr_tag_type_inconsistent)
        << Context.ToCtx.getTypeDeclType(Owner2);
    Context.Diag2(Field2->getLocation(), diag::note_odr_field_name)
        << Field2->getDeclName();
    Context.Diag1(Field1->getLocation(), diag::note_odr_field_name)
        << Field1->getDeclName();
  return false;

We change this to be always a Warning instead of an Error in this patch:

So currently will this fail for cases that clang proper would not?

Well, I think the situation is more subtle than that.
There are cases when we can link two translation units and the linker provides a valid executable even if there is an ODR violation of a type. There is no type information used during linkage, except for functions' mangled names and visibility. That ODR violation is recognized though when we do the merge in the AST level (and I think it is useful to diagnose them).
So if "clang proper" includes the linker then the answer is yes. If not then we are talking about only one translation unit and the answer is no.

martong marked an inline comment as done.Mar 14 2019, 9:39 AM

@shafik Ping

shafik accepted this revision.Mar 15 2019, 9:37 AM


This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 19 2019, 6:33 AM