| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Post-commit review by Kim Grasman!
llvm-svn: 321457
|
|
|
|
|
|
|
| |
Extend the hashing to functions, which allows detection of function definition
mismatches across modules. This is a re-commit of r320230.
llvm-svn: 321395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
llvm-svn: 321312
|
|
|
|
| |
llvm-svn: 320239
|
|
|
|
|
|
|
| |
Extend the hashing to functions, which allows detection of function definition
mismatches across modules.
llvm-svn: 320230
|
|
|
|
|
|
|
|
|
| |
templates too.
While here, split the "point of instantiation changed" notification out from
it; these two really are orthogonal changes.
llvm-svn: 319727
|
|
|
|
|
|
|
|
|
|
| |
whether they have an initializer.
We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.
llvm-svn: 319605
|
|
|
|
| |
llvm-svn: 319601
|
|
|
|
|
|
|
|
|
|
|
| |
These functions were defined as static members of TemplateSpecializationType.
Now they are moved to namespace level. Previously there were different
implementations for lists containing TemplateArgument and TemplateArgumentLoc,
now these implementations share the same code.
This change is a result of refactoring patch D40508. NFC.
llvm-svn: 319178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we merge together class definitions, we can end up with the canonical
declaration of a field not being the one that was lexically within the
canonical definition of the class. Additionally, when we merge class
definitions via update records (eg, for a template specialization whose
declaration is instantiated in one module and whose definition is instantiated
in multiple others), we can end up with the list of lexical contents for the
class not including a particular declaration of a field whose lexical parent is
that class definition. In the worst case, we have a field whose canonical
declaration's lexical parent has no fields, and in that case this attempt to
number the fields by walking the fields in the declaration of the class that
contained one of the canonical fields will fail.
Instead, when numbering fields in a class, do the obvious thing: walk the
fields in the definition.
I'm still trying to reduce a testcase; the setup that leads to the above
scenario seems to be quite fragile.
llvm-svn: 318245
|
|
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 318101
|
|
|
|
|
|
|
|
|
|
|
|
| |
name the same namespace.
They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.
llvm-svn: 316965
|
|
|
|
|
|
| |
double square bracket attributes in C code.
llvm-svn: 316026
|
|
|
|
|
|
|
|
|
|
| |
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
|
|
|
|
|
|
| |
This reverts commit r315251. See the original commit thread for reason.
llvm-svn: 315309
|
|
|
|
|
|
|
|
| |
DeclContext for a declaration in the global module."
This reverts commit r315256. See the original commit thread for reason.
llvm-svn: 315308
|
|
|
|
|
|
|
|
|
|
| |
declaration in the global module.
This works around a language issue where adding a typedef name for linkage
purposes changes the linkage of an already-defined class after it becomes
complete.
llvm-svn: 315256
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
|
|
|
|
| |
llvm-svn: 314754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the follow-up patch to D37924.
This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:
[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*
The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.
Reviewers: pcc, kcc, eugenis, vsk
Reviewed By: eugenis
Subscribers: dberris, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37925
llvm-svn: 314171
|
|
|
|
|
|
|
| |
We used to give such members no linkage instead of giving them the linkage of
the class.
llvm-svn: 314054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.
We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.
We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.
llvm-svn: 314037
|
|
|
|
|
|
| |
purposes), so they never formally have linkage.
llvm-svn: 313957
|
|
|
|
|
|
|
|
|
|
|
| |
variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
llvm-svn: 313955
|
|
|
|
| |
llvm-svn: 313953
|
|
|
|
|
|
|
|
|
|
| |
variables and variable templates."
To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind'
This reverts commit r313827.
llvm-svn: 313856
|
|
|
|
|
|
|
|
| |
variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
llvm-svn: 313827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
|
|
|
|
|
|
|
|
|
|
|
|
| |
This follows the scheme agreed with Nathan Sidwell, which can be found here:
https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile
This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.
llvm-svn: 312467
|
|
|
|
|
|
|
| |
This would be trivial, except that our in-memory and serialized representations
for FieldDecls assumed that this can't happen.
llvm-svn: 311867
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r310436 with actual functional changes. Please
see that commit message for a description of why a cache is appearing
here.
Suggestions for less-bad ways of testing this are appreciated. :)
This fixes PR29160.
llvm-svn: 310437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is patch 1 in a 2 patch series that aims to fix PR29160. Its goal
is to cache decl visibility/linkage for the duration of each
visibility+linkage query.
The simplest way I can see to do this is to put the visibility
calculation code that needs to (transitively) access this cache into a
class, which is what this patch does. Actual caching will come in patch
2. (Another way would be to keep the cache in ASTContext + manually
invalidate it or something, but that felt way too subtle to me.)
Caching visibility results across multiple queries seems a bit tricky,
since the user can add visibility attributes ~whenever they want, and
these attributes can apparently have far-reaching effects (e.g. class
visibility extends to its members, ...). Because a cache that's dropped
at the end of each top-level query seems to work nearly as well and
doesn't require any eviction logic, I opted for that design.
llvm-svn: 310436
|
|
|
|
|
|
|
|
|
|
| |
on macOS
Fixes PR33796, rdar://33655115
Differential revision: https://reviews.llvm.org/D36191
llvm-svn: 310382
|
|
|
|
| |
llvm-svn: 310299
|
|
|
|
|
|
|
|
|
|
| |
In addition to the formal linkage rules, the Modules TS includes cases where
internal-linkage symbols within a module interface unit can be referenced from
outside the module via exported inline functions / templates. We give such
declarations "module-internal linkage", which is formally internal linkage, but
results in an externally-visible symbol.
llvm-svn: 307434
|
|
|
|
|
|
|
|
|
|
| |
In C mode clang fails to merge the textually included definition with the one imported from a module. The C lookup rules fail to find the imported definition because its linkage is internal in non C++ mode.
This patch reinstates some of the ODR merging rules for typedefs of anonymous tags for languages other than C++.
Patch by Raphael Isemann and me (D34510).
llvm-svn: 306964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Redeclaration lookup should never find hidden enumerators in C, because
they do not have linkage (C11 6.2.2/6)
The linkage of an enumerator should be VisibleNoLinkage, and
isHiddenDeclarationVisible should be checking hasExternalFormalLinkage.
This is was reviewed as part of D31778, but splitted into a different
commit for clarity.
rdar://problem/31909368
llvm-svn: 306917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.
Reviewers: rjmccall, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33735
llvm-svn: 305075
|
|
|
|
|
|
|
|
|
|
| |
Modifies FunctionDecl::isThisDeclarationADefinition so that it covers
all the cases checked by FunctionDecl::isDefined. Implements the latter
method by call to isThisDeclarationADefinition.
This change is a part of the patch D30170.
llvm-svn: 304684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
This reinstates r302965, reverted in r303037, with a fix for the reported
crash, which occurred when reparenting a local declaration to be a child of
a hidden imported declaration (specifically during template instantiation).
llvm-svn: 303224
|
|
|
|
|
|
|
|
|
| |
module immediately
Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.
llvm-svn: 303037
|
|
|
|
|
|
|
|
|
|
| |
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
llvm-svn: 302965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
merged template.
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
This reinstates r300650, reverted in r300659, with a fix for a regression
reported by Chandler after commit.
llvm-svn: 300938
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original idea was that if the attribute on an operator,
that the return-value unused-ness wouldn't matter. However,
all of the operators except postfix inc/dec return
references! References don't result in this warning
anyway, so those are already excluded.
Differential Revision: https://reviews.llvm.org/D32207
llvm-svn: 300764
|
|
|
|
|
|
|
|
|
|
| |
modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.
Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged template.
llvm-svn: 300659
|
|
|
|
| |
llvm-svn: 300653
|
|
|
|
|
|
|
|
|
|
|
|
| |
merged template.
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
llvm-svn: 300650
|
|
|
|
|
|
|
|
|
| |
properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp."
This reverts commit r300443. Breaks compiling libc++ with modules in
some configurations.
llvm-svn: 300497
|