Commit Graph

568 Commits

Author SHA1 Message Date
Nico Weber c9276fbfdf Revert "[NFC] Refactor representation of materialized temporaries"
This reverts commit 08ea1ee2db.
It broke ./ClangdTests/FindExplicitReferencesTest.All
on the bots, see comments on https://reviews.llvm.org/D69360
2019-11-17 02:09:25 -05:00
Tyker 08ea1ee2db [NFC] Refactor representation of materialized temporaries
Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: rnkovacs, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69360
2019-11-16 17:56:09 +01:00
Balázs Kéri c2f6efc732 [Clang][ASTImporter] Added visibility check for ClassTemplateDecl.
Summary:
ASTImporter makes now difference between class templates with same
name in different translation units if these are not visible outside.

Reviewers: martong, a.sidorin, shafik

Reviewed By: martong

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67543
2019-11-15 15:05:26 +01:00
Adrian Prantl 2073dd2da7 Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.
This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting
with DWARF 5 all Objective-C methods are nested inside their
containing type, and that patch implements this for synthesized
Objective-C properties.

1. SemaObjCProperty populates a list of synthesized accessors that may
   need to inserted into an ObjCImplDecl.

2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all
   accessors for which no override was provided into their
   ObjCImplDecl. This patch does *not* synthesize AST function
   *bodies*. Moving that code from the static analyzer into Sema may
   be a good idea though.

3. Places that expect all methods to have bodies have been updated.

I did not update the static analyzer's inliner for synthesized
properties to point back to the property declaration (see
test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which
I believed to be more bug than a feature.

Differential Revision: https://reviews.llvm.org/D68108

rdar://problem/53782400
2019-11-08 08:23:22 -08:00
Raphael Isemann ba7bde65dc [ASTImporter] Add support for BuiltinTemplateDecl
Summary:
That decl kind is currently not implemented. BuiltinTemplateDecl is for decls that are hardcoded in the
ASTContext, so we can import them like we do other builtin decls by just taking the equivalent
decl from the target ASTContext.

Reviewers: martong, a.sidorin, shafik

Reviewed By: martong, shafik

Subscribers: rnkovacs, kristina, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69566
2019-10-30 14:53:35 +01:00
Michael Liao 243ebfba17 [hip][cuda] Fix the extended lambda name mangling issue.
Summary:
- HIP/CUDA host side needs to use device kernel symbol name to match the
  device side binaries. Without a consistent naming between host- and
  device-side compilations, it's risky that wrong device binaries are
  executed. Consistent naming is usually not an issue until unnamed
  types are used, especially the lambda. In this patch, the consistent
  name mangling is addressed for the extended lambdas, i.e. the lambdas
  annotated with `__device__`.
- In [Itanium C++ ABI][1], the mangling of the lambda is generally
  unspecified unless, in certain cases, ODR rule is required to ensure
  consisent naming cross TUs. The extended lambda is such a case as its
  name may be part of a device kernel function, e.g., the extended
  lambda is used as a template argument and etc. Thus, we need to force
  ODR for extended lambdas as they are referenced in both device- and
  host-side TUs. Furthermore, if a extended lambda is nested in other
  (extended or not) lambdas, those lambdas are required to follow ODR
  naming as well. This patch revises the current lambda mangle numbering
  to force ODR from an extended lambda to all its parent lambdas.
- On the other side, the aforementioned ODR naming should not change
  those lambdas' original linkages, i.e., we cannot replace the original
  `internal` with `linkonce_odr`; otherwise, we may violate ODR in
  general. This patch introduces a new field `HasKnownInternalLinkage`
  in lambda data to decouple the current linkage calculation based on
  mangling number assigned.

[1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Reviewers: tra, rsmith, yaxunl, martong, shafik

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D68818

llvm-svn: 375309
2019-10-19 00:15:19 +00:00
Simon Pilgrim 4706f3be88 Fix uninitialized variable warnings. NFCI.
llvm-svn: 374876
2019-10-15 10:23:05 +00:00
Richard Smith 91aeacc06b Move most CXXRecordDecl::DefinitionData bit-fields out into a separate
file.

Reduces duplication and thereby reduces the risk that someone will
forget to update one of these places, as I did when adding
DefaultedDestructorIsConstexpr (though I've been unable to produce
a testcase for which that matters so far).

llvm-svn: 374484
2019-10-11 00:29:04 +00:00
Richard Smith 772e266fbf Properly handle instantiation-dependent array bounds.
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.

llvm-svn: 373685
2019-10-04 01:25:59 +00:00
Richard Smith 457226e02a For P0784R7: add support for constexpr destructors, and call them as
appropriate during constant evaluation.

Note that the evaluator is sometimes invoked on incomplete expressions.
In such cases, if an object is constructed but we never reach the point
where it would be destroyed (and it has non-trivial destruction), we
treat the expression as having an unmodeled side-effect.

llvm-svn: 372538
2019-09-23 03:48:44 +00:00
Balazs Keri f8a89c8fa7 [Clang][ASTImporter] Added visibility check for FunctionTemplateDecl.
Summary:
ASTImporter makes now difference between function templates with same
name in different translation units if these are not visible outside.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67490

llvm-svn: 371820
2019-09-13 08:03:49 +00:00
Balazs Keri c86d47b6b6 [ASTImporter] Added visibility context check for TypedefNameDecl.
Summary:
ASTImporter makes now difference between typedefs and type aliases
with same name in different translation units
if these are not visible outside.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: martong, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64480

llvm-svn: 370903
2019-09-04 14:12:18 +00:00
Balazs Keri 6e08669879 [ASTImporter] At import of records re-order indirect fields too.
Summary:
Correct order of fields and indirect fields in imported RecordDecl
is needed for correct work of record layout calculations.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: martong, a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66866

llvm-svn: 370621
2019-09-02 07:17:01 +00:00
Gabor Marton e3e83d708a [ASTImporter] Do not look up lambda classes
Summary:
Consider this code:
```
      void f() {
        auto L0 = [](){};
        auto L1 = [](){};
      }

```
First we import `L0` then `L1`. Currently we end up having only one
CXXRecordDecl for the two different lambdas. And that is a problem if
the body of their op() is different. This happens because when we import
`L1` then lookup finds the existing `L0` and since they are structurally
equivalent we just map the imported L0 to be the counterpart of L1.

We have the same problem in this case:
```
      template <typename F0, typename F1>
      void f(F0 L0 = [](){}, F1 L1 = [](){}) {}

```

In StructuralEquivalenceContext we could distinquish lambdas only by
their source location in these cases. But we the lambdas are actually
structrually equivalent they differn only by the source location.

Thus, the  solution is to disable lookup completely if the decl in
the "from" context is a lambda.
However, that could have other problems: what if the lambda is defined
in a header file and included in several TUs? I think we'd have as many
duplicates as many includes we have. I think we could live with that,
because the lambda classes are TU local anyway, we cannot just access
them from another TU.

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66348

llvm-svn: 370461
2019-08-30 10:55:41 +00:00
Balazs Keri b4fd7d4258 [ASTImporter] Propagate errors during import of overridden methods.
Summary:
If importing overridden methods fails for a method it can be seen
incorrectly as non-virtual. To avoid this inconsistency the method
is marked with import error to avoid later use of it.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: martong, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66933

llvm-svn: 370457
2019-08-30 10:12:14 +00:00
Gabor Marton f035b75d8f [ASTImporter] Fix name conflict handling with different strategies
There are numorous flaws about the name conflict handling, this patch
attempts fixes them. Changes in details:

* HandleNameConflict return with a false DeclarationName

Hitherto we effectively never returned with a NameConflict error, even
if the preceding StructuralMatch indicated a conflict.
Because we just simply returned with the parameter `Name` in
HandleNameConflict and that name is almost always `true` when converted to
`bool`.

* Add tests which indicate wrong NameConflict handling

* Add to ConflictingDecls only if decl kind is different

Note, we might not indicate an ODR error when there is an existing record decl
and a enum is imported with same name.  But there are other cases. E.g. think
about the case when we import a FunctionTemplateDecl with name f and we found a
simple FunctionDecl with name f. They overload.  Or in case of a
ClassTemplateDecl and CXXRecordDecl, the CXXRecordDecl could be the 'templated'
class, so it would be false to report error.  So I think we should report a
name conflict error only when we are 100% sure of that.  That is why I think it
should be a general pattern to report the error only if the kind is the same.

* Fix failing ctu test with EnumConstandDecl

In ctu-main.c we have the enum class 'A' which brings in the enum
constant 'x' with value 0 into the global namespace.
In ctu-other.c we had the enum class 'B' which brought in the same name
('x') as an enum constant but with a different enum value (42). This is clearly
an ODR violation in the global namespace. The solution was to rename the
second enum constant.

 * Introduce ODR handling strategies

Reviewers: a_sidorin, shafik

Differential Revision: https://reviews.llvm.org/D59692

llvm-svn: 370045
2019-08-27 11:36:10 +00:00
Duncan P. N. Exon Smith f584819085 ContentCache: Drop getBuffer's dependency on SourceManager
Refactor ContentCache::IsSystemFile to IsFileVolatile, checking
SourceManager::userFilesAreVolatile at construction time.  This is a
step toward lowering ContentCache down from SourceManager to
FileManager.

No functionality change intended.

https://reviews.llvm.org/D66713

llvm-svn: 369958
2019-08-26 20:32:05 +00:00
Balazs Keri e13e836480 [ASTImporter] Import ctor initializers after setting flags.
Summary:
Code to import "ctor initializers" at import of functions
is moved to be after the flags in the newly created function
are imported. This fixes an error when the already created but
incomplete (flags are not set) function declaration is accessed.

Reviewers: martong, shafik, a_sidorin, a.sidorin

Reviewed By: shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65935

llvm-svn: 369098
2019-08-16 12:10:03 +00:00
Balazs Keri c509594319 [ASTImporter] Import default expression of param before creating the param.
Summary:
The default expression of a parameter variable should be imported before
the parameter variable object is created. Otherwise the function is created
with an incomplete parameter variable (default argument is nullptr) and in
this intermediary state the expression is imported. This import can have
a reference to the incomplete parameter variable that causes crash.

Reviewers: martong, a.sidorin, shafik

Reviewed By: martong

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65577

llvm-svn: 368818
2019-08-14 09:41:39 +00:00
Balazs Keri b427c061ad [ASTImporter] Import additional flags for functions.
Summary:
At AST import of function delcarations import the flags for defaulted
and deleted.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65999

llvm-svn: 368655
2019-08-13 08:04:06 +00:00
Balazs Keri 2e16060a8b [ASTImporter] Fix for import of friend class template with definition.
Summary:
If there is a friend class template "prototype" (forward declaration)
and later a definition for it in the existing code, this existing
definition may be not found by ASTImporter because it is not linked
to the prototype (under the friend AST node). The problem is fixed by
looping over all found matching decls instead of break after the first
found one.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65269

llvm-svn: 368551
2019-08-12 10:07:38 +00:00
Richard Sandiford eb485fbc71 Add SVE opaque built-in types
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:

   https://developer.arm.com/docs/100986/0000

It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:

   (1) trying to generate LLVM IR for the types
   (2) trying to generate debug info for the types
   (3) trying to mangle the types using the Microsoft C++ ABI
   (4) trying to @encode the types in Objective C

(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change.  There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.

The intention is that the types will become sizeless types:

   http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html

The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.

Until then, the patch sets the alignments of the types to the values
specified in the link above.  It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).

The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other.  After this patch, the two pieces of work are
essentially independent.

The patch is based on one by Graham Hunter:

   https://reviews.llvm.org/D59245

Differential Revision: https://reviews.llvm.org/D62960

llvm-svn: 368413
2019-08-09 08:52:54 +00:00
Balazs Keri e9719f9e9e [ASTImporter] Do not import FunctionTemplateDecl in record twice.
Summary:
For functions there is a check to not duplicate the declaration if it is in a
record (class). For function templates there was no similar check, if a
template (in the same class) was imported multiple times the
FunctionTemplateDecl was created multiple times with the same templated
FunctionDecl. This can result in problems with the declaration chain.

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65203

llvm-svn: 368163
2019-08-07 12:40:17 +00:00
Harlan Haskins 8d323d1506 [clang] Adopt new FileManager error-returning APIs
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367616
2019-08-01 21:31:56 +00:00
Gabor Marton 48b16e1005 [ASTImporter] Reorder fields after structure import is finished
We reorder declarations in RecordDecls because they may have another order
in the "to" context than they have in the "from" context. This may happen
e.g when we import a class like this:
   struct declToImport {
       int a = c + b;
       int b = 1;
       int c = 2;
   };
During the import of `a` we import first the dependencies in sequence,
thus the order would be `c`, `b`, `a`. We will get the normal order by
first removing the already imported members and then adding them in the
order as they apper in the "from" context.

Keeping field order is vital because it determines structure layout.

Reviewers: a_sidorin, shafik

Tags: #clang

Differential Revision: https://reviews.llvm.org/D44100

llvm-svn: 366997
2019-07-25 09:07:17 +00:00
Balazs Keri d22f877356 [CrossTU] Add a function to retrieve original source location.
Summary:
A new function will be added to get the original SourceLocation
for a SourceLocation that was imported as result of getCrossTUDefinition.
The returned SourceLocation is in the context of the (original)
SourceManager for the original source file. Additionally the
ASTUnit object for that source file is returned. This is needed
to get a SourceManager to operate on with the returned source location.

The new function works if multiple different source files are loaded
with the same CrossTU context.

Reviewers: martong, shafik

Reviewed By: martong

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65064

llvm-svn: 366884
2019-07-24 10:16:37 +00:00
Ilya Biryukov abc744d263 Revert r366449: [CrossTU] Add a function to retrieve original source location.
Reason: the commit breaks layering by adding a dependency on ASTUnit
(which is inside clangFrontend) from the ASTImporter (which is inside
clangAST).

llvm-svn: 366453
2019-07-18 15:43:26 +00:00
Balazs Keri d2c576110e [CrossTU] Add a function to retrieve original source location.
Summary:
A new function will be added to get the original SourceLocation
for a SourceLocation that was imported as result of getCrossTUDefinition.
The returned SourceLocation is in the context of the (original)
SourceManager for the original source file. Additionally the
ASTUnit object for that source file is returned. This is needed
to get a SourceManager to operate on with the returned source location.

The new function works if multiple different source files are loaded
with the same CrossTU context.

This patch can be treated as part of a bigger change that is needed to
improve macro expansion handliong at plist generation.

Reviewers: martong, shafik, a_sidorin, xazax.hun

Reviewed By: martong

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64554

llvm-svn: 366449
2019-07-18 15:23:10 +00:00
Gabor Marton aefcf5100a [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage.  The solution is to use noload_lookup, which
works well with transparent contexts.  But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.

These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().

We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.

Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits

Tags: #clang, #lldb

Differential Revision: https://reviews.llvm.org/D61333

llvm-svn: 366325
2019-07-17 13:47:46 +00:00
Simon Pilgrim 130df2c7e8 Fix uninitialized variable analyzer warning. NFCI.
llvm-svn: 366062
2019-07-15 13:00:43 +00:00
Balazs Keri eb79b25b44 [ASTImporter] Added visibility context check for EnumDecl.
Summary:
ASTImporter makes now difference between enums with same name in different translation
units if these are not visible outside.
("Scoped enums" are not handled yet.)

Reviewers: martong, a.sidorin, shafik, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62484

llvm-svn: 365464
2019-07-09 11:08:18 +00:00
Gabor Marton e73805f80e [ASTImporter] Fix import of lambda in function param
Summary:
The current import implementation fails to import the definition of a
lambda class if the lambda class is defined in a function param.
E.g., the lambda class below will be imported without any methods:
```
  template <typename F>
  void f(F L = [](){}) {}
```

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64073

llvm-svn: 365315
2019-07-08 12:49:13 +00:00
Gabor Marton 2afbfb6b22 [ASTImporter] Mark erroneous nodes in shared st
Summary:
Now we store the errors for the Decls in the "to" context too. For
that, however, we have to put these errors in a shared state (among all
the ASTImporter objects which handle the same "to" context but different
"from" contexts).

After a series of imports from different "from" TUs we have a "to" context
which may have erroneous nodes in it. (Remember, the AST is immutable so
there is no way to delete a node once we had created it and we realized
the error later.) All these erroneous nodes are marked in
ASTImporterSharedState::ImportErrors.  Clients of the ASTImporter may
use this as an input. E.g. the static analyzer engine may not try to
analyze a function if that is marked as erroneous (it can be queried via
ASTImporterSharedState::getImportDeclErrorIfAny()).

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62376

llvm-svn: 364785
2019-07-01 15:37:07 +00:00
Benjamin Kramer 4f769361e3 [ASTImporter] Silence unused variable warning in Release builds. NFC.
llvm-svn: 364774
2019-07-01 14:33:26 +00:00
Gabor Marton 1ad4b99d94 [ASTImporter] Mark erroneous nodes in from ctx
Summary:
During import of a specific Decl D, it may happen that some AST nodes
had already been created before we recognize an error. In this case we
signal back the error to the caller, but the "to" context remains
polluted with those nodes which had been created. Ideally, those nodes
should not had been created, but that time we did not know about the
error, the error happened later.  Since the AST is immutable (most of
the cases we can't remove existing nodes) we choose to mark these nodes
as erroneous.
Here are the steps of the algorithm:
1) We keep track of the nodes which we visit during the import of D: See
ImportPathTy.
2) If a Decl is already imported and it is already on the import path
(we have a cycle) then we copy/store the relevant part of the import
path. We store these cycles for each Decl.
3) When we recognize an error during the import of D then we set up this
error to all Decls in the stored cycles for D and we clear the stored
cycles.

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62375

llvm-svn: 364771
2019-07-01 14:19:53 +00:00
Gabor Marton 17c3eafb2e [ASTImporter] Propagate error from ImportDeclContext
Summary:
During analysis of one project we failed to import one
CXXDestructorDecl. But since we did not propagate the error in
importDeclContext we had a CXXRecordDecl without a destructor. Then the
analyzer engine had a CallEvent where the nonexistent dtor was requested
(crash).

Solution is to propagate the errors we have during importing a
DeclContext.

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63603

llvm-svn: 364752
2019-07-01 12:44:39 +00:00
Gabor Marton 303c9861e9 [ASTImporter] Store import errors for Decls
Summary:
We add a new member which is a mapping from the already-imported
declarations in the "from" context to the error status of the import of
that declaration.  This map contains only the declarations that were not
correctly imported. The same declaration may or may not be included in
ImportedDecls. This map is updated continuously during imports and never
cleared (like ImportedDecls).  In Import(Decl*) we use this mapping, so
if there was a previous failed import we return with the existing error.

We add/remove from the Lookuptable in consistency with ImportedFromDecls.
When we map a decl in the 'to' context to something in the 'from'
context then and only then we add it to the lookup table. When we
remove a mapping then and only then we remove it from the lookup table.

This patch is the first in a series of patches whose aim is to further
strengthen the error handling in ASTImporter.

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62373

llvm-svn: 364279
2019-06-25 08:00:51 +00:00
Gauthier Harnisch 83c7b61052 [clang] Add storage for APValue in ConstantExpr
Summary:
When using ConstantExpr we often need the result of the expression to be kept in the AST. Currently this is done on a by the node that needs the result and has been done multiple times for enumerator, for constexpr variables... . This patch adds to ConstantExpr the ability to store the result of evaluating the expression. no functional changes expected.

Changes:
 - Add trailling object to ConstantExpr that can hold an APValue or an uint64_t. the uint64_t is here because most ConstantExpr yield integral values so there is an optimized layout for integral values.
 - Add basic* serialization support for the trailing result.
 - Move conversion functions from an enum to a fltSemantics from clang::FloatingLiteral to llvm::APFloatBase. this change is to make it usable for serializing APValues.
 - Add basic* Import support for the trailing result.
 - ConstantExpr created in CheckConvertedConstantExpression now stores the result in the ConstantExpr Node.
 - Adapt AST dump to print the result when present.

basic* : None, Indeterminate, Int, Float, FixedPoint, ComplexInt, ComplexFloat,
the result is not yet used anywhere but for -ast-dump.

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: rnkovacs, hiraditya, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62399

llvm-svn: 363493
2019-06-15 10:24:47 +00:00
Gauthier Harnisch 796ed03b84 [C++20] add Basic consteval specifier
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html

with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.

Changes:
 - add the consteval keyword.
 - add parsing of consteval specifier for normal declarations and lambdas expressions.
 - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
 - adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
 - add tests for basic semantic.

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: eraman, efriedma, rnkovacs, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61790

llvm-svn: 363362
2019-06-14 08:56:20 +00:00
Richard Smith 1bbad59379 For DR712: store on a MemberExpr whether it constitutes an odr-use.
llvm-svn: 363087
2019-06-11 17:50:36 +00:00
Richard Smith 715f7a1bd0 For DR712: store on a DeclRefExpr whether it constitutes an odr-use.
Begin restructuring to support the forms of non-odr-use reference
permitted by DR712.

llvm-svn: 363086
2019-06-11 17:50:32 +00:00
Gabor Marton dd2b76e13e [ASTImporter] Fix unhandled cases in ASTImporterLookupTable
Summary:
In most cases the FriendDecl contains the declaration of the befriended
class as a child node, so it is discovered during the recursive
visitation. However, there are cases when the befriended class is not a
child, thus it must be fetched explicitly from the FriendDecl, and only
then can we add it to the lookup table.
(Note, this does affect only CTU and does not affect LLDB, because we
cannot and do not use the ASTImporterLookupTable in LLDB.)

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62064

llvm-svn: 363062
2019-06-11 13:35:25 +00:00
Jennifer Yu b8fee677bf Re-check in clang support gun asm goto after fixing tests.
llvm-svn: 362410
2019-06-03 15:57:25 +00:00
Erich Keane d0f34fd198 Revert "clang support gnu asm goto."
This reverts commit 954ec09aed.

Reverting due to test failures as requested by Jennifer Yu.

Conflicts:
	clang/test/CodeGen/asm-goto.c

llvm-svn: 362106
2019-05-30 15:38:02 +00:00
Jennifer Yu 954ec09aed clang support gnu asm goto.
Syntax:
  asm [volatile] goto ( AssemblerTemplate
                      :
                      : InputOperands
                      : Clobbers
                      : GotoLabels)

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

New llvm IR is "callbr" for inline asm goto instead "call" for inline asm
For:
asm goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop);
IR:
callbr void asm sideeffect "testl $0, $0; jne ${1:l};", "r,X,X,~{dirflag},~{fpsr},~{flags}"(i32 %0, i8* blockaddress(@foo, %label_true), i8* blockaddress(@foo, %loop)) #1
          to label %asm.fallthrough [label %label_true, label %loop], !srcloc !3

asm.fallthrough:                                

Compiler need to generate:
1> a dummy constarint 'X' for each label.
2> an unique fallthrough label for each asm goto stmt " asm.fallthrough%number".


Diagnostic 
1>	duplicate asm operand name are used in output, input and label.
2>	goto out of scope.

llvm-svn: 362045
2019-05-30 01:05:46 +00:00
Balazs Keri c8272195cd [ASTImporter] Added visibility context check for CXXRecordDecl.
Summary:
ASTImporter makes now difference between classes with same name in different
translation units if these are not visible outside. These classes are not linked
into one decl chain.

Reviewers: martong, a.sidorin, shafik

Reviewed By: shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62312

llvm-svn: 361752
2019-05-27 09:36:00 +00:00
Shafik Yaghmour 468724eed2 [ASTImporter] Call to HandleNameConflict in VisitRecordDecl mistakeningly using Name instead of SearchName
Summary:
https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitRecordDecl for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via D->getTypedefNameForAnonDecl()->getDeclName().

This fix is very similar to https://reviews.llvm.org/D59665

Differential Revision: https://reviews.llvm.org/D62352

llvm-svn: 361650
2019-05-24 16:53:44 +00:00
Simon Pilgrim 4c146ab8c4 ASTNodeImporter - fix uninitialized variable warnings. NFCI.
llvm-svn: 361096
2019-05-18 11:33:27 +00:00
Eric Fiselier 708afb56c1 Implement __builtin_LINE() et. al. to support source location capture.
Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. 

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

Differential Revision: https://reviews.llvm.org/D37035

llvm-svn: 360937
2019-05-16 21:04:15 +00:00
Gabor Marton 5ac6d49065 [ASTImporter] Use llvm::Expected and Error in the importer API
Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves the following:
- remove old Import functions which returned with a pointer,
- use the Import_New functions (which return with Err or Expected) everywhere
  and handle their return value
- rename Import_New functions to Import
This affects both Clang and LLDB.

Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits

Tags: #clang, #lldb

Differential Revision: https://reviews.llvm.org/D61438

llvm-svn: 360760
2019-05-15 10:29:48 +00:00