| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During reading C++ definition data for lambda we can access
CXXRecordDecl representing lambda before we finished reading the
definition data. This can happen by reading a captured variable which is
VarDecl, then reading its decl context which is CXXMethodDecl `operator()`,
then trying to merge redeclarable methods and accessing
enclosing CXXRecordDecl. The call stack looks roughly like
VisitCXXRecordDecl
ReadCXXRecordDefinition
VisitVarDecl
VisitCXXMethodDecl
mergeRedeclarable
getPrimaryContextForMerging
If we add fake definition data at this point, later we'll hit the assertion
Assertion failed: (!DD.IsLambda && !MergeDD.IsLambda && "faked up lambda definition?"), function MergeDefinitionData, file clang/lib/Serialization/ASTReaderDecl.cpp, line 1675.
The fix is to assign definition data before reading it. Fixes PR32556.
rdar://problem/37461072
Reviewers: rsmith, bruno
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple, aprantl
Differential Revision: https://reviews.llvm.org/D43494
llvm-svn: 328153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.
Previously the loop in emitPseudoObjectExpr would emit the IR for each
OpaqueValueExpr that was in a PseudoObjectExpr's semantic-form
expression list and use the result when the OpaqueValueExpr later
appeared in other expressions. This caused an assertion failure when
AggExprEmitter tried to copy the result of an OpaqueValueExpr and the
copied type didn't have trivial copy/move constructors or assignment
operators.
This patch adds flag IsUnique to OpaqueValueExpr which indicates it is a
unique reference to its source expression (it is not used in multiple
places). The loop in emitPseudoObjectExpr ignores OpaqueValueExprs that
are unique and CodeGen visitors simply traverse the source expressions
of such OpaqueValueExprs.
rdar://problem/34363596
Differential Revision: https://reviews.llvm.org/D39562
llvm-svn: 327939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
This recommits r327206, which was reverted because it caused
module-enabled builders to fail. I discovered that the
CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in
some cases after I moved it to RecordDecl.
Thanks to Eric Liu for helping me investigate the bug.
rdar://problem/33599681
https://reviews.llvm.org/D44095
llvm-svn: 327870
|
|
|
|
|
|
|
|
|
|
| |
The patch adds nocf_check target independent attribute for disabling checks that were enabled by cf-protection flag.
The attribute can be appertained to functions and function pointers.
Attribute name follows GCC's similar attribute name.
Differential Revision: https://reviews.llvm.org/D41880
llvm-svn: 327768
|
|
|
|
|
|
| |
rdar://problem/38421774
llvm-svn: 327434
|
|
|
|
|
|
|
|
|
|
|
| |
ARC."
This reverts commit r327206 as there were test failures caused by this
patch.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180312/221427.html
llvm-svn: 327294
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44095
llvm-svn: 327206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Re-applying r326501.)
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc
comments or not.
2. "Maybe-doc" comments, like <, !, etc, are saved as such, instead of marking
them as ordinary comments. The maybe-doc type of comment is never saved
otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Subscribers: cfe-commits
llvm-svn: 326512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original change:
[NFC] Move CommentOpts checks to the call sites that depend on it.
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc comments or not.
2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
llvm-svn: 326508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc
comments or not.
2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of
marking them as ordinary comments. The maybe-doc type of comment is never
saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are
ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43663
llvm-svn: 326501
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
llvm-svn: 326416
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the HashString function from StringExtraces and
replaces its uses with calls to djbHash from DJB.h.
This change is *almost* NFC. While the algorithm is identical, the
djbHash implementation in StringExtras used 0 as its default seed while
the implementation in DJB uses 5381. The latter has been shown to result
in less collisions and improved avalanching and is used by the DWARF
accelerator tables.
Because some test were implicitly relying on the hash order, I've
reverted to using zero as a seed for the following two files:
lld/include/lld/Core/SymbolTable.h
llvm/lib/Support/StringMap.cpp
Differential revision: https://reviews.llvm.org/D43615
llvm-svn: 326091
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like some of our tests depend on the ordering of hashed values.
I'm reverting my changes while I try to reproduce and fix this locally.
Failing builds:
lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388
lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743
lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607
llvm-svn: 326082
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the HashString function from StringExtraces and replaces
its uses with calls to djbHash from DJB.h
This is *almost* NFC. While the algorithm is identical, the djbHash
implementation in StringExtras used 0 as its seed while the
implementation in DJB uses 5381. The latter has been shown to result in
less collisions and improved avalanching.
https://reviews.llvm.org/D43615
(cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c)
llvm-svn: 326081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic settings using _Pragma within a macro.
The AST writer had previously been assuming that all diagnostic state
transitions would occur within a FileID corresponding to a file. When a
diagnostic state change occured within a macro, it was unable to form a
location for that state change and would instead corrupt the diagnostic state
of the "root" node (and thus that of the main compilation).
Also introduce a "#pragma clang __debug diag_mapping" debugging utility
that I added to track this issue down.
llvm-svn: 324695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'trivial_abi' attribute can be applied to a C++ class, struct, or
union. It makes special functions of the annotated class (the destructor
and copy/move constructors) to be trivial for the purpose of calls and,
as a result, enables the annotated class or containing classes to be
passed or returned using the C ABI for the underlying type.
When a type that is considered trivial for the purpose of calls despite
having a non-trivial destructor (which happens only when the class type
or one of its subobjects is a 'trivial_abi' class) is passed to a
function, the callee is responsible for destroying the object.
For more background, see the discussions that took place on the mailing
list:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043
rdar://problem/35204524
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 324269
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TemplateTemplateParmDecls of alias templates
TemplateTemplateParmDecls of alias templates ended-up serialized as 'file-level decls' which was causing a crash while trying to index a PCH/module file that contained them.
Commit makes sure TemplateTemplateParmDecls are not recorded as such kind of decls.
Fixes crash of rdar://36608297
Differential Revision: https://reviews.llvm.org/D42588
llvm-svn: 323549
|
|
|
|
|
|
|
|
| |
The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit.
Differential Revision: https://reviews.llvm.org/D20124
llvm-svn: 322503
|
|
|
|
|
|
| |
then use that logic when evaluating constant expressions and emitting codegen.
llvm-svn: 322074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
|
|
|
|
|
|
|
|
|
| |
Attempting to recompute it are doomed to fail because the IDNS of a declaration
is not necessarily preserved across serialization and deserialization (in turn
because whether a friend declaration is visible depends on whether some prior
non-friend declaration exists).
llvm-svn: 321921
|
|
|
|
|
|
|
|
|
| |
The patch fixes r321395, that cuased
-Werror=unused-but-set-variable issue for
Diagnosed var on prod build.
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 321854
|
|
|
|
|
|
|
|
|
|
|
|
| |
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
llvm-svn: 321628
|
|
|
|
|
|
|
|
|
|
|
|
| |
TypeSpecifierType into scoped enums with underlying types.
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.
Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614
https://reviews.llvm.org/rC321615
llvm-svn: 321622
|
|
|
|
|
|
|
|
| |
- the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.
Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)
llvm-svn: 321616
|
|
|
|
| |
llvm-svn: 321615
|
|
|
|
|
|
| |
Saves a pointer on every CompoundStmt.
llvm-svn: 321429
|
|
|
|
|
|
|
| |
Extend the hashing to functions, which allows detection of function definition
mismatches across modules. This is a re-commit of r320230.
llvm-svn: 321395
|
|
|
|
|
|
| |
Convert most uses to range-for loops. No functionality change intended.
llvm-svn: 320954
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
The current code would hit an assert in ASTWriter when trying to write
out the filename for a line table entry that didn't have any. Fix this
by allowing the -1 sentinel value to round-trip through serialization.
Differential revision: https://reviews.llvm.org/D40746
llvm-svn: 319707
|
|
|
|
|
|
| |
changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes.
llvm-svn: 319688
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
parallel for`.
Add support for cancel/cancellation point directives inside `target
teams distribute parallel for` directives.
llvm-svn: 318881
|
|
|
|
|
|
|
|
|
| |
parallel for directives.
Added codegen/sema support for cancel constructs in [teams] distribute
parallel for directives.
llvm-svn: 318872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
search path
When mixing PCH and Implicit Modules, missing a header search path
can lead to the implicit built PCM to complaint about not finding its
matching module map.
Instead of adding more magic to implicit modules engine, add a note to
help the user add the appropriate path.
rdar://problem/33388847
llvm-svn: 318503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FunctionDecl.
The anonymous union did NOT save us storage, but instead behaved as if we added an additional integer data member to FunctionDecl.
For additional context, the anonymous union renders the bit fields as non-adjacent and prevents them from sharing the same 'memory location' (i.e. bit-storage) by requiring the anonymous union object to be appropriately aligned.
This was confirmed through discussion with Richard Smith in Albuquerque (ISO C++ Meeting)
https://reviews.llvm.org/rL316292
llvm-svn: 317984
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 317953
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 317648
|
|
|
|
|
|
|
|
|
|
| |
When a preamble ends in a conditional preprocessor block that is being
skipped, the preprocessor needs to continue skipping that block when
the preamble is used.
This fixes PR34570.
llvm-svn: 317308
|
|
|
|
|
|
|
|
| |
Since they'll likely (not always - if the address is taken, etc) be
inlined away, even at -O0, separately provided weak definitions are
likely to be unused so skip all of that.
llvm-svn: 317279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consistent with various workarounds in the backwards compatible modules
that allow static functions in headers to exist, be deduplicated to some
degree, and not generally fail right out of the gate... do the same with
modular codegen as there are enough cases (including in libstdc++ and in
LLVM itself - though I cleaned up the easy ones) that it's worth
supporting as a migration/backcompat step.
Simply create a separate, internal linkage function in each object that
needs it. If an available_externally/modularized function references a
static function, but the modularized function is eventually dropped and
not inlined, the static function will be dropped as unreferenced.
llvm-svn: 317274
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 317273
|
|
|
|
|
|
|
|
|
| |
for instantiating its definition.
We model the 'inline'ness as being instantiated with the static data member in
order to track whether the declaration has become a definition yet.
llvm-svn: 317147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deduction-guides in line with WG21's p0620r0.
In order to identify the copy deduction candidate, I considered two approaches:
- attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution.
- using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides
After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union.
Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added.
References:
See https://bugs.llvm.org/show_bug.cgi?id=34970
See http://wg21.link/p0620r0
llvm-svn: 316292
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 315573
|
|
|
|
|
|
|
|
|
|
|
| |
deserialization."
This is breaking a build of https://github.com/abseil/abseil-cpp and so
likely not really NFC. Also reverted subsequent r314956/7.
I'll forward reproduction instructions to Richard.
llvm-svn: 315439
|