[PATCH] D50451: [ASTImporter] Fix import of class templates partial specialization
Gabor Marton via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 14 04:21:20 PDT 2018
martong marked 5 inline comments as done.
martong added inline comments.
================
Comment at: lib/AST/ASTImporter.cpp:2872
Importer.MapImported(D, FoundField);
+ // In case of a FieldDecl of a ClassTemplateSpecializationDecl, the
+ // initializer of a FieldDecl might not had been instantiated in the
----------------
a_sidorin wrote:
> Honestly speaking, I wonder about this behaviour because it doesn't look similar to instantiation of only methods that are used. Is it a common rule?
Yes, this is a common rule. The instantiation of an initializer is similar to the instantiation of default arguments in a sense that both are instantated only if they are being used.
To be more precise, quoting from Vandevoorde - C++ Templates The Complete Guide / 14.2.2 Instantiated Components:
... Default function call arguments are considered separately when instantiating
templates. Specifically, they are not instantiated unless there is a call to that
function (or member function) that actually makes use of the default argument.
If, on the other hand, the function is called with explicit arguments that override
the default, then the default arguments are not instantiated.
Similarly, exception specifications and **default member initializers** are not
instantiated unless they are needed.
================
Comment at: lib/AST/ASTImporter.cpp:4550
+ // in the "From" context, but not in the "To" context.
+ for (auto *FromField : D->fields())
+ Importer.Import(FromField);
----------------
a_sidorin wrote:
> Importing additional fields can change the layout of the specialization. For CSA, this usually results in strange assertions hard to debug. Could you please share the results of testing of this change?
> This change also doesn't seem to have related tests in this patch.
TLDR; We will not create additional fields.
By the time when we import the field, we already know that the existing specialization is structurally equivalent with the new one.
Since a ClassTemplateSpecializationDecl is the descendant of RecordDecl, the structural equivalence check ensures that they have the exact same fields.
When we import the field of the new spec and if there is an existing FieldDecl in the "To" context, then no new FieldDecl will be created (this is handled in `VisitFieldDecl` by first doing a lookup of existing field with the same name and type).
This patch extends `VisitFieldDecl` in a way that we add new initializer expressions to the existing FieldDecl, if it didn't have and in the "From" context it has.
For the record, I added a new test to make sure that a new FieldDecl will not be created during the merge.
================
Comment at: lib/AST/ASTImporter.cpp:4551
+ for (auto *FromField : D->fields())
+ Importer.Import(FromField);
+
----------------
a_sidorin wrote:
> The result of import is unchecked here and below. Is it intentional?
Yes, that is intentional. We plan to refactor all ASTImporter functions to provide a proper error handling mechanism, and in that change we would like to enforce the check of all import functions.
Unfortunately, currently we already have many places where we do not check the return value of import.
Repository:
rC Clang
https://reviews.llvm.org/D50451
More information about the cfe-commits
mailing list