Re-commit r303463 now that LLVM is fixed and adjust some lit tests.
llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.
Differential Revision: https://reviews.llvm.org/D32982
llvm-svn: 303478
Let's revert this for now (and with it the assert()) to get the bots
back to green until I have LLVM synced up properly.
This reverts commit r303463.
llvm-svn: 303474
Summary:
The trial parse for declarative syntax accepts an invalid pack
declaration syntax, which is ambiguous with valid pack expansions of
expressions. This commit removes the invalid pack declaration syntax to
avoid mistaking valid pack expansions as invalid declarator components.
Additionally, the trial parse of a //template-argument-list// then needs
to handle the optional ellipsis that is part of that grammar, as opposed
to relying on the trial parse for declarators accepting stray ellipses.
Reviewers: rsmith, rcraik, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33339
llvm-svn: 303472
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
llvm-svn: 303469
When reaching the end of a module, we used to convert its macros to
ModuleMacros but also leave them in the MacroDirective chain for the
identifier. This meant that every lookup of such a macro would find two
(identical) definitions. It also made it difficult to determine the correct
owner for a macro when reaching the end of a module: the most recent
MacroDirective in the chain could be from an #included submodule rather than
the current module.
Simplify this: whenever we convert a MacroDirective to a ModuleMacro when
leaving a module, clear out the MacroDirective chain for that identifier, and
just rely on the ModuleMacro to provide the macro definition information.
(We don't want to do this for local submodule visibility mode, because in that
mode we maintain a distinct MacroDirective chain for each submodule, and we
need to keep around the prior MacroDirective in case we re-enter the submodule
-- for instance, if its header is #included more than once in a module build,
we need the include guard directive to stick around. But the problem doesn't
arise in this case for the same reason: each submodule has its own
MacroDirective chain, so the macros don't leak out of submodules in the first
place.)
This reinstates r302932, reverted in r302947, with a fix for a bug that
resulted in us sometimes losing macro definitions due to failing to clear out
the overridden module macro list when promoting a directive to a module macro.
llvm-svn: 303468
llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.
Differential Revision: https://reviews.llvm.org/D32982
llvm-svn: 303463
As discussed in D30793, we have some unsafe calls to isConsumerInterestedIn().
This patch implements Richard's suggestion (from the inline comment) that we
should track if we just deserialized an declaration. If we just deserialized,
we can skip the unsafe call because we know it's interesting. If we didn't just
deserialize the declaration, calling isConsumerInterestedIn() should be safe.
We tried to create a test case for this but we were not successful.
Patch by Raphael Isemann (D32499)!
llvm-svn: 303432
Summary:
This patch updates the handling of multiline trailing comment sections in
import statement lines to make it more consistent with the case in general.
This includes updating the parsing logic to collect the trailing comment
sections and the formatting logic to not insert escaped newlines at the end of
comment lines in import statement lines.
Specifically, before this patch this code:
```
#include <a> // line 1
// line 2
```
will be turned into two unwrapped lines, whereas this code:
```
int i; // line 1
// line 2
```
is turned into a single unwrapped line, enabling reflowing across comments.
An example where the old behaviour is bad is when partially formatting the lines
3 to 4 of this code:
```
#include <a> // line 1
// line 2
int i;
```
which gets turned into:
```
#include <a> // line 1
// line 2
int i;
```
because the two comment lines were independent and the indent was copied.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33351
llvm-svn: 303415
Summary:
The syntax is actually `for await (const x of y)` (d'oh).
This also fixes a crash for `for` tokens not followed by additional tokens.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33329
llvm-svn: 303382
specification and the TU to the new module.
This is necessary to get the module ownership correct for entities that we
temporarily hang off the TranslationUnitDecl, such as template parameters and
function parameters.
llvm-svn: 303373
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
looking up a dependent name in a record that derives from itself
rdar://32273000
Differential Revision: https://reviews.llvm.org/D33324
llvm-svn: 303366
The functions creating LValues propagated information about alignment
source. Extend the propagated data to also include information about
possible unrestricted aliasing. A new class LValueBaseInfo will
contain both AlignmentSource and MayAlias info.
This patch should not introduce any functional changes.
Differential Revision: https://reviews.llvm.org/D33284
llvm-svn: 303358
Summary:
Computed line index must be relative to the current 'parent' node, and
thus use CurrentLines instead of Lines.
Without this, a child line's MatchingOpeningBlockLineIndex is out of
range of the parent's list of line, which can cause crash or unexpected
behavior if this field is used in childs.
Contributed by @Typz!
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32524
llvm-svn: 303353
Summary:
This patch makes NoLineBreakFormatter to insert a break before tokens where
MustBreakBefore is true.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33238
llvm-svn: 303332
Summary:
Doxygen supports putting documentation blocks after member, by adding
an additional < marker in the comment block. This patch makes sure
this marker is used in lines which are introduced by breaking the
comment.
int foo; ///< Some very long comment.
becomes:
int foo; ///< Some very long
///< comment.
Contributed by @Typz!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33282
llvm-svn: 303330
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
Summary:
OnDiskData.TemporaryFiles is filled only by ASTUnit::addTemporaryFile, which is
dead. Also these files are used nowhere in the frontend nor in libclang.
Reviewers: bkramer, ilya-biryukov
Reviewed By: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33270
llvm-svn: 303265
retrieving the identifer info for an Objective-C keyword
This commit fixes an assertion that's triggered in getIdentifier when the token
is an annotation token.
rdar://32225463
llvm-svn: 303246
(2) Removed uncessary anymore \c commands, since the same effect will be achived by <c> ... </c> sequence.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 303228
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
This fixes a regression introduced in r302915.
Using the lexical decl context is not necessary here for what r302915
wast trying to achieve. Not canonicalizing the NamespaceDecl in
getOrCreateNamespace is suficient.
rdar://problem/29339538
llvm-svn: 303222
Even though the shouldInlineCall function returns true, it can happen that the
function is not going to be inlined (as it can be seen at line 913 and below).
Moved the bumpNumTimesInlined(D) (the counter increaser) call to the inlineCall
function where it logically belongs.
Differential Revision: https://reviews.llvm.org/D32179
llvm-svn: 303158
This commit fixes a bug that's tracked by PR 10758 and duplicates like PR 30343.
The bug causes clang to crash with a stack overflow while recursing infinitely
trying to perform copy-initialization on a type without a copy constructor but
with a constructor that accepts another type that can be constructed using the
original type.
The commit fixes this bug by detecting the recursive behavior and failing
correctly with an appropriate error message. It also tries to provide a
meaningful diagnostic note about the constructor which leads to this behavior.
rdar://28483944
Differential Revision: https://reviews.llvm.org/D25051
llvm-svn: 303156
This fix UBSAN bots after r302935. Storing non-defined values in enum is
undefined behavior.
Other places, where "if (ScalarCast != CK_Invalid)" is used, never get to the
"if" with CK_Invalid. tryGCCVectorConvertAndSplat can get to the "if" with
CK_Invalid and it looks like expected case. So we have to use something other
than CK_Invalid, e.g. CK_NoOp.
llvm-svn: 303121
Currently clang checks for default data sharing attributes only for
variables captured in OpenMP regions by reference. Patch adds checks for
variables captured by value.
llvm-svn: 303077
myFunction(param1, param2,);
For symmetry with other parenthesized lists ([...], {...}), clang-format should
wrap parenthesized lists one-per-line if they contain a trailing comma:
myFunction(
param1,
param2,
);
This is particularly useful in function declarations or calls with many
arguments, e.g. commonly in constructors.
Differential Revision: https://reviews.llvm.org/D33023
llvm-svn: 303049
Summary:
`getIdentifierInfo()` includes all keywords, whereas non-null assertion
operators should only be recognized after non-keywords or pseudo keywords.
Ideally this should list all tokens that clang-format recognizes as a keyword,
but that are pseudo or no keywords in JS. For the time being, just recognize
the specific bits users ran into (`namespace` in this case).
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33182
llvm-svn: 303038
module immediately
Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.
llvm-svn: 303037
Separated very long brief sections into two sections.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 303031
https://bugs.llvm.org/show_bug.cgi?id=32933
Turns out clang wasn't really handling vla's (*) in C++11's for-range entirely correctly.
For e.g. This would lead to generation of buggy IR:
void foo(int b) {
int vla[b];
b = -1; // This store would affect the '__end = vla + b'
for (int &c : vla)
c = 0;
}
Additionally, code-gen would get confused when VLA's were reference-captured by lambdas, and then used in a for-range, which would result in an attempt to generate IR for '__end = vla + b' within the lambda's body - without any capture of 'b' - hence the assertion.
This patch modifies clang, so that for VLA's it translates the end pointer approximately into:
__end = __begin + sizeof(vla)/sizeof(vla->getElementType())
As opposed to the __end = __begin + b;
I considered passing a magic value into codegen - or having codegen special case the '__end' variable when it referred to a variably-modified type, but I decided against that approach, because it smelled like I would be increasing a complicated form of coupling, that I think would be even harder to maintain than the above approach (which can easily be optimized (-O1) to refer to the run-time bound that was calculated upon array's creation or copied into the lambda's closure object).
(*) why oh why gcc would you enable this by default?! ;)
llvm-svn: 303026
ASTImporter has some bugs when it's importing types
that themselves come from an ExternalASTSource. This
is exposed particularly in the behavior when
comparing complete TagDecls with forward
declarations. This patch does several things:
- Adds a test case making sure that conflicting
forward-declarations are resolved correctly;
- Extends the clang-import-test harness to test
two-level importing, so that we make sure we
complete types when necessary; and
- Fixes a few bugs I found this way. Failure to
complete types was one; however, I also discovered
that complete RecordDecls aren't properly added to
the redecls chain for existing forward
declarations.
llvm-svn: 302975
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
Summary:
Clang changes to remove this option and replace with a parameter
always set in the context of a ThinLTO distributed backend.
Depends on D33133.
Reviewers: pcc
Subscribers: mehdi_amini, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D33134
llvm-svn: 302940
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.
If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.
Contributions from: Petar Jovanovic
Reviewers: bruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D25866
llvm-svn: 302935
When reaching the end of a module, we used to convert its macros to
ModuleMacros but also leave them in the MacroDirective chain for the
identifier. This meant that every lookup of such a macro would find two
(identical) definitions. It also made it difficult to determine the correct
owner for a macro when reaching the end of a module: the most recent
MacroDirective in the chain could be from an #included submodule rather than
the current module.
Simplify this: whenever we convert a MacroDirective to a ModuleMacro when
leaving a module, clear out the MacroDirective chain for that identifier, and
just rely on the ModuleMacro to provide the macro definition information.
(We don't want to do this for local submodule visibility mode, because in that
mode we maintain a distinct MacroDirective chain for each submodule, and we
need to keep around the prior MacroDirective in case we re-enter the submodule
-- for instance, if its header is #included more than once in a module build,
we need the include guard directive to stick around. But the problem doesn't
arise in this case for the same reason: each submodule has its own
MacroDirective chain, so the macros don't leak out of submodules in the first
place.)
llvm-svn: 302932
This addresses review feedback from r302840.
By not canonicalizing namespace decls and using lexical decl context
instead of lookuing up the semantic decl context we can take advantage
of the fact that DINamespaces a reuniqued. This way non-module debug
info is unchanged and module debug info still gets distinct namespace
declarations when they ocur in different modules.
Thanks to Richard Smith for pointing this out!
llvm-svn: 302915
This diff
1. adds missing "explicit" for single argument constructors
2. adds missing std::move in ReplaceNodeWithTemplate constructor
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D33061
llvm-svn: 302855
When we parse a redefinition of an entity for which we have a hidden existing
declaration, make it visible in the current module instead of mapping the
current source location to its containing module.
llvm-svn: 302842
The AST merges NamespaceDecls, but for module debug info it is
important to put a namespace decl (or rather its children) into the
correct (sub-)module, so we need to use the parent module of the decl
that triggered this namespace to be serialized as a second key when
looking up DINamespace nodes.
rdar://problem/29339538
llvm-svn: 302840
in list-initialization, run cleanups for the default argument after each
iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the
complete loop, rather than once per iteration!
Re-commit of r302750, reverted in r302776.
llvm-svn: 302817
type is a TemplateSpecializationType or InjectedClassNameType
Fixes PR30847. Partially fixes PR20973 (first position only).
PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.
rdar://29818301
llvm-svn: 302797
Revert "clang/test/CodeGenCXX/array-default-argument.cpp: Satisfy targets that have x86_thiscallcc."
This reverts commit r302750 and its fixup r302757 because the test is
still breaking on some of the ARM bots.
array-default-argument.cpp:20:12: error: expected string not found in input
// CHECK: {{call|invoke}}[[THISCALL:( x86_thiscallcc)?]] void @_ZN1AC1Ev([[TEMPORARY:.*]])
^
<stdin>:18:1: note: scanning from here
arrayctor.loop: ; preds = %arrayctor.loop, %entry
^
<stdin>:28:2: note: possible intended match here
call void @_Z1fv()
^
--
llvm-svn: 302776
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 302775
Diagnostics related to redefinition errors that point to the same header
file do not provide much information that helps users fixing the issue.
- In the modules context, it usually happens because of non modular
includes.
- When modules aren't involved it might happen because of the lack of
header guards.
Enhance diagnostics in these scenarios.
Differential Revision: https://reviews.llvm.org/D28832
rdar://problem/31669175
llvm-svn: 302765
in list-initialization, run cleanups for the default argument after each
iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the
complete loop, rather than once per iteration!
llvm-svn: 302750
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
As discovered by ChenWJ and listed on cfe-dev, the error for Objective C
return type ended up being wrong. This fixes that. Additionally, as a
"while we're there", the other usages of this error and the usage of the
FP above both use a FixItHint, so I'll add it here.
Differential Revision: https://reviews.llvm.org/D32759
llvm-svn: 302720
Modified MipsABIInfo::classifyArgumentType so that it now coerces
aggregate structures only if the size of said aggregate is less than
16/64 bytes, depending on the ABI.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D32900
with minor changes (use regexp instead of the hardcoded values) to the test.
llvm-svn: 302670
Summary:
For C++ code, opening parenthesis following a } indicate a braced init. For JavaScript and other languages, this is an invalid syntactical construct, unless the closing parenthesis belongs to a function - in which situation its a BK_Block.
This fixes indenting IIFEs following top level functions:
function foo() {}
(function() { codeHere(); }());
clang-format used to collapse these lines together.
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33006
llvm-svn: 302658
This commit implements basic support for indexing of dependent declaration
references. Now the indexer tries to find a suitable match in the base template
for a dependent member ref/decl ref/dependent type.
rdar://29158210
Differential Revision: https://reviews.llvm.org/D32972
llvm-svn: 302632
Summary: This is the first change as part of developing a clang-query based search and replace tool.
Reviewers: klimek, bkramer, ioeric, sbenza, jbangert
Reviewed By: ioeric, jbangert
Subscribers: sbenza, ioeric, cfe-commits
Patch by Julian Bangert!
Differential Revision: https://reviews.llvm.org/D29621
llvm-svn: 302624
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
llvm-svn: 302615
Sanitizer instrumentation generally needs to be marked with !nosanitize,
but we're not doing this properly for ubsan's overflow checks.
r213291 has more information about why this is needed.
llvm-svn: 302598
This improves our behavior in a few ways:
* We now guarantee that if a member is marked as being a member
specialization, there will actually be a member specialization declaration
somewhere on its redeclaration chain. This fixes a crash in modules builds
where we would try to check that there was a visible declaration of the
member specialization and be surprised to not find any declaration of it at
all.
* We don't set the source location of the in-class declaration of the member
specialization to the out-of-line declaration's location until we have
actually finished merging them. This fixes some very silly looking
diagnostics, where we'd point a "previous declaration is here" note at the
same declaration we're complaining about. Ideally we wouldn't mess with the
prior declaration's location at all, but too much code assumes that the
first declaration of an entity is a reasonable thing to use as an indication
of where it was declared, and that's not really true for a member
specialization unless we fake it like this.
llvm-svn: 302596
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
llvm-svn: 302591
Because IIFEs[1] are often used like an anonymous namespace around large
sections of JavaScript code, it's useful not to indent to them (which
effectively reduces the column limit by the indent amount needlessly).
It's also common for developers to wrap these around entire files or
libraries. When adopting clang-format, changing the indent entire file
can reduce the usefulness of the blame annotations.
Patch by danbeam, thanks!
Differential Revision: https://reviews.llvm.org/D32989
llvm-svn: 302580
Use variadic templates instead of relying on <cstdarg> + sentinel.
This enforces better type checking and makes code more readable.
Differential revision: https://reviews.llvm.org/D32550
llvm-svn: 302572
Add the toolchain installation directory to the program
path so that lld can be found.
Change -flavor to wasm. Although this new flavor hasn't
yet landed in upstream lld yet there are no point in
passing wasm objects the gnu flavor.
Differential Revision: https://reviews.llvm.org/D32976
llvm-svn: 302558
Reverting
Modified MipsABIInfo::classifyArgumentType so that it now coerces
aggregate structures only if the size of said aggregate is less than 16/64
bytes, depending on the ABI.
as it broke clang-with-lto-ubuntu builder.
llvm-svn: 302555
Modified MipsABIInfo::classifyArgumentType so that it now coerces aggregate
structures only if the size of said aggregate is less than 16/64 bytes,
depending on the ABI.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D32900
llvm-svn: 302547
`__builtin_available`
This commit allows us to use the macOS/iOS/tvOS/watchOS platform names in
`@available`/`__builtin_available`.
rdar://32067795
Differential Revision: https://reviews.llvm.org/D33000
llvm-svn: 302540
This fixes the bug: https://bugs.llvm.org/show_bug.cgi?id=32638
int main()
{
[](auto x) noexcept(noexcept(x)) { } (0);
}
In the above code, prior to this patch, when substituting into the noexcept expression, i.e. transforming the DeclRefExpr that represents 'x' - clang attempts to capture 'x' because Sema's CurContext is still pointing to the pattern FunctionDecl (i.e. the templated-decl set in FinishTemplateArgumentDeduction) which does not match the substituted 'x's DeclContext, which leads to an attempt to capture and an assertion failure.
We fix this by adjusting Sema's CurContext to point to the substituted FunctionDecl under which the noexcept specifier's argument should be transformed, and so the ParmVarDecl that 'x' refers to has the same declcontext and no capture is attempted.
I briefly investigated whether the SwitchContext should occur right after VisitMethodDecl creates the new substituted FunctionDecl, instead of only during instantiating the exception specification - but seeing no other code that seemed to rely on that, I decided to leave it just for the duration of the exception specification instantiation.
llvm-svn: 302507
We were sometimes doing a function->pointer conversion in
Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr.
So, when we saw typeof(OverloadedFunctionName), where
OverloadedFunctionName referenced a name with only one function that
could have its address taken, we'd give back a function pointer type
instead of a function type. This is incorrect.
I kept the logic for doing the function pointer conversion in
resolveAndFixAddressOfOnlyViableOverloadCandidate because it was more
consistent with existing ResolveAndFix* methods.
llvm-svn: 302506
When a type in a class is from a typedef, only check the canonical type. Skip
checking the intermediate underlying types. This is in response to PR 32965
llvm-svn: 302505
It appears that the code is actually dead since unbridged-cast
placeholder types are created by calling CastOperation::complete and
ImplicitCastExprs are never passed to it.
Spotted by Vedant Kumar.
rdar://problem/31542226
llvm-svn: 302503
blocks.
r302270 made changes to avoid emitting clang.arc.use at -O0 and instead
emit @objc_release. We also have to emit @objc_retain for the captured
variable at -O0 to match the @objc_release instead of just storing the
pointer to the capture field.
llvm-svn: 302495
Summary:
We define the `__xray_customeevent` builtin that gets translated to
IR calls to the correct intrinsic. The default implementation of this is
a no-op function. The codegen side of this follows the following logic:
- When `-fxray-instrument` is not provided in the driver, we elide all
calls to `__xray_customevent`.
- When `-fxray-instrument` is enabled and a function is marked as "never
instrumented", we elide all calls to `__xray_customevent` in that
function; if either marked as "always instrumented" or subject to
threshold-based instrumentation, we emit a call to the
`llvm.xray.customevent` intrinsic from LLVM for each
`__xray_customevent` occurrence in the function.
This change depends on D27503 (to land in LLVM first).
Reviewers: echristo, rsmith
Subscribers: mehdi_amini, pelikan, lrl, cfe-commits
Differential Revision: https://reviews.llvm.org/D30018
llvm-svn: 302492
In r298391 we fixed the umbrella framework model to work when submodules
named "Private" are used. This complements the work by allowing the
umbrella framework model to work in general.
rdar://problem/31790067
llvm-svn: 302491
When enabling any sanitizer, -fsanitize-use-after-scope is enabled by
default. This doesn't actually turn ASan on, because we've been getting
lucky and there are extra checks in BackendUtil that stop this from
happening.
However, this has been causing a behavior change: extra lifetime markers
are emitted in some cases where they aren't needed or expected.
llvm-svn: 302468
In C typos in arguments in a call of an overloadable function lead
to a failure of construction of CallExpr and following recovery does
not handle created delayed typos. This causes an assertion fail in
Sema::~Sema since Sema::DelayedTypos remains not empty.
The patch fixes that behavior by handling a call with arguments
having dependant types in the way that C++ does.
Differential Revision: https://reviews.llvm.org/D31764
Patch by Dmitry Borisenkov!
llvm-svn: 302435
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Differential Revision: https://reviews.llvm.org/D32770
llvm-svn: 302418
It turns out there are some sort-of-but-not-quite empty structs that break all
the rules. For example:
struct SuperEmpty { int arr[0]; };
struct SortOfEmpty { struct SuperEmpty e; };
Both of these have sizeof == 0, even in C++ mode, for GCC compatibility. The
first one also doesn't occupy a register when passed by value in GNU C++ mode,
unlike everything else.
On Darwin, we want to ignore the lot (and especially don't want to try to use
an i0 as we were).
llvm-svn: 302313
To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.
Ignoring line markers, a preprocessed module might look like this:
module A {
header "a.h"
}
#pragma clang module contents
#pragma clang module begin A
// ... a.h ...
#pragma clang module end
The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.
A couple of major parts do not work yet:
1) The files that are listed in the module map must exist on disk, in order to
build the on-disk header -> module lookup table in the PCM file. To fix
this, we need the preprocessed output to track the file size and other stat
information we might use to build the lookup table.
2) Declaration ownership semantics don't work properly yet, since mapping from
a source location to a module relies on mapping from FileIDs to modules,
which we can't do if module transitions can occur in the middle of a file.
llvm-svn: 302309
Summary:
This adds a new ASTMatcher for CXXStdInitializerListExprs that matches C++ initializer list expressions.
The primary motivation is to use it to fix [[ https://bugs.llvm.org/show_bug.cgi?id=32896 | PR32896 ]] (review here [[ https://reviews.llvm.org/D32767 | D32767 ]]).
Reviewers: alexfh, Prazek, aaron.ballman
Reviewed By: alexfh, aaron.ballman
Subscribers: malcolm.parsons, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32810
llvm-svn: 302287
Summary:
When the function is compiled with soft-float or on CPU with no FPU, we
don't need to diagnose for a call from an ISR to a regular function.
Reviewers: jroelofs, eli.friedman
Reviewed By: jroelofs
Subscribers: aemerson, rengolin, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D32918
llvm-svn: 302274
The clang.arc.use intrinsic is removed via the ARC Contract Pass. This
pass is only executed in optimized builds (>= opt level 1). Prevent the
optimization implemented in SVN r301667 from triggering at optimization
level 0 like every other ARC use intrinsic usage.
llvm-svn: 302270
This patch adds a fix-it for the -Wunguarded-availability warning. This fix-it
is similar to the Swift one: it suggests that you wrap the statement in an
`if (@available)` check. The produced fixits are indented (just like the Swift
ones) to make them look nice in Xcode's fix-it preview.
rdar://31680358
Differential Revision: https://reviews.llvm.org/D32424
llvm-svn: 302253
whose introduced version is lower than the allowed version.
We should just rely on the target version as this introduced version can lead
to false positives (e.g. deprecated declarations).
rdar://31964333
llvm-svn: 302250
Add an opt-in warning that fires when 0 is used as a null pointer.
gcc has this warning, and there's some demand for it.
https://reviews.llvm.org/D32914
llvm-svn: 302247
This is because -print-multi-lib depends on them being flags for correctness.
Fixes a case of this in the arm-android multilib selection logic.
llvm-svn: 302207
The whitespace should come from the argument name in the macro
expansion, rather than from the token passed to the macro (same as it
does when not pasting).
Added a new test case for the change in behavior to stringize_space.c.
FileCheck'ized macro_paste_commaext.c, tweaked the test case, and
added a comment; no behavioral change to this test.
Differential Revision: https://reviews.llvm.org/D30427
llvm-svn: 302195
Summary:
First, getCurFunction looks through blocks and lambdas, which is wrong.
Inside a lambda, va_start should refer to the lambda call operator
prototype. This fixes PR32737.
Second, we shouldn't use any of the getCur* methods, because they look
through contexts that we don't want to look through (EnumDecl,
CapturedStmtDecl). We can use CurContext directly as the calling
context.
Finally, this code assumed that CallExprs would never appear outside of
code contexts (block, function, obj-c method), which is wrong. Struct
member initializers are an easy way to create and parse exprs in a
non-code context.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D32761
llvm-svn: 302188
When building with libc++ don't bother with injecting the libstdc++
search paths into the linker search path. This will make it easier to
switch between ld and lld.
llvm-svn: 302184
Summary: While its precedence should be higher than multiplicative, LLVM does not have a level for that, so for the time being just treat it as multiplicative.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32864
llvm-svn: 302156
delayed diagnostic
This fix avoids an infinite recursion that was uncovered in one of our internal
tests by r301992. The testcase is the most reduced version of that
auto-generated test.
This is an improved version of the reverted commit r302037. The previous fix
actually managed to expose another subtle bug whereby `fatal_too_many_errors`
error was reported twice, with the second report setting the
`FatalErrorOccurred` flag. That prevented the notes that followed the diagnostic
the caused `fatal_too_many_errors` to be emitted. This commit ensures that notes
that follow `fatal_too_many_errors` but that belong to the diagnostic that
caused `fatal_too_many_errors` won't be emitted by setting the
`FatalErrorOccurred` when emitting `fatal_too_many_errors`.
rdar://31962618
llvm-svn: 302151
specializations that 'override' declarations in the base template should use
the 'specializationOf' relation instead of 'specializationOf | overrideOf'.
The indexer relations are meant to be orthogonal, so 'specializationOf' is
better than the combined relation.
llvm-svn: 302136
Implemented the remaining integer data processing intrinsics from
the ARM ACLE v2.1 spec, such as parallel arithemtic and DSP style
multiplications.
Differential Revision: https://reviews.llvm.org/D32282
llvm-svn: 302131
When profiling a no-op incremental link of Chromium I found that the functions
computeImportForFunction and computeDeadSymbols were consuming roughly 10% of
the profile. The goal of this change is to improve the performance of those
functions by changing the map lookups that they were previously doing into
pointer dereferences.
This is achieved by changing the ValueInfo data structure to be a pointer to
an element of the global value map owned by ModuleSummaryIndex, and changing
reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs.
This means that a ValueInfo will take a client directly to the summary list
for a given GUID.
Differential Revision: https://reviews.llvm.org/D32471
llvm-svn: 302108
These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.
Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).
llvm-svn: 302098
Summary:
Do three things to help with that:
- Add AttributeList::FirstArgIndex, which is an enumerator currently set
to 1. It allows us to change the indexing scheme with fewer changes.
- Add addParamAttr/removeParamAttr. This just shortens addAttribute call
sites that would otherwise need to spell out FirstArgIndex.
- Remove some attribute-specific getters and setters from Function that
take attribute list indices. Most of these were only used from
BuildLibCalls, and doesNotAlias was only used to test or set if the
return value is malloc-like.
I'm happy to split the patch, but I think they are probably easier to
review when taken together.
This patch should be NFC, but it sets the stage to change the indexing
scheme to this, which is more convenient when indexing into an array:
0: func attrs
1: retattrs
2...: arg attrs
Reviewers: chandlerc, pete, javed.absar
Subscribers: david2050, llvm-commits
Differential Revision: https://reviews.llvm.org/D32811
llvm-svn: 302060
delayed diagnostic
This avoids an infinite loop that was uncovered in one of our internal tests
by r301992. The testcase is the most reduced version of that auto-generated
test.
rdar://31962618
llvm-svn: 302037
https://reviews.llvm.org/D32807
This patch allows the map modifier 'always' to be separated by the map type (to, from, tofrom) only by a whitespace, rather than strictly by a comma as in current trunk.
llvm-svn: 302031
In a previous patch, a new generic error diagnostic for inconsistent attributes was added.
In this commit I reuse this diagnostic for ns_returns_retained attribute check.
Differential Revision: https://reviews.llvm.org/D32697
llvm-svn: 302024
It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").
rdar://problem/31718115
Differential Revision: https://reviews.llvm.org/D32702
llvm-svn: 302016
I think this is a false positive in GCC's warning, but nonetheless, we
should try to be warning-free. Smaller reproducer (reproduces with GCC
6.3):
https://godbolt.org/g/cJuO2z
llvm-svn: 302003
The intent for an explicit module build is that the diagnostics produced within
the module are those that were configured when the module was built, not those
that are enabled within a user of the module. This includes diagnostics that
don't actually show up until the module is used (for instance, diagnostics
produced during template instantiation and weird cases like -Wpadded).
We serialized and restored the diagnostic state for individual warning groups,
but previously did not track the state for flags like -Werror and -Weverything,
which are implemented as separate bits rather than as part of the diagnostics
mapping information.
llvm-svn: 301992
Currently, ubsan emits overflow checks for arithmetic that is known to
be safe at compile-time, e.g:
1 + 1 => CheckedAdd(1, 1)
This leads to breakage when using the __builtin_prefetch intrinsic. LLVM
expects the arguments to @llvm.prefetch to be constant integers, and
when ubsan inserts unnecessary checks on the operands to the intrinsic,
this contract is broken, leading to verifier failures (see PR32874).
Instead of special-casing __builtin_prefetch for ubsan, this patch fixes
the underlying problem, i.e that clang currently emits unnecessary
overflow checks.
Testing: I ran the check-clang and check-ubsan targets with a stage2,
ubsan-enabled build of clang. I added a regression test for PR32874, and
some extra checking to make sure we don't regress runtime checking for
unsafe arithmetic. The existing ubsan-promoted-arithmetic.cpp test also
provides coverage for this change.
llvm-svn: 301988
When computing the appropriate cv-qualifiers for the 'this' capture, we have to examine each enclosing lambda - but when using the FunctionScopeInfo stack we have to ensure that the lambda below (outer) is the decl-context of the closure-class of the current lambda.
https://bugs.llvm.org/show_bug.cgi?id=32831
This patch was initially committed here: https://reviews.llvm.org/rL301735
Then reverted here: https://reviews.llvm.org/rL301916
The issue with the original patch was a failure to check that the closure type has been created within the LambdaScopeInfo before querying its DeclContext - instead of just assuming it has (silly!). A reduced example such as this highlights the problem:
struct X {
int data;
auto foo() { return [] { return [] -> decltype(data) { return 0; }; }; }
};
When 'data' within decltype(data) tries to determine the type of 'this', none of the LambdaScopeInfo's have their closure types created at that point.
llvm-svn: 301972
Combine the logic doing the ms_abi/sysv_abi checks into one function so
that each check and its logical opposite are near each other. Now we
don't need two Sema entry points for MS va_start and regular va_start.
Refactor the code that checks if the va_start caller is a function,
block, or obj-c method. We do this in three places, and they are all
buggy for variadic lambdas (PR32737). After this change, I have one
place to apply the functional fix.
NFC
llvm-svn: 301968
handling of constexprs with unknown bounds.
This triggers a corner case of the language where it's not yet clear
whether this should be an error:
struct A {
static void *const a[];
static void *const b[];
};
constexpr void *A::a[] = {&b[0]};
constexpr void *A::b[] = {&a[0]};
When discovering the initializer for A::a, the bounds of A::b aren't known yet.
It is unclear whether warning about errors should be deferred until the end of
the translation unit, possibly resolving errors that can be resolved. In
practice, the compiler can know the bounds of all arrays in this example.
Credits for reproducers and explanation go to Richard Smith. Richard, please
add more info in case my explanation is wrong.
llvm-svn: 301963
It leads to clang crashing, e.g. on this short code fragment (added to
test/SemaCXX/warn-thread-safety-parsing.cpp):
class SomeClass {
public:
void foo() {
auto l = [this] { auto l = [] EXCLUSIVE_LOCKS_REQUIRED(mu_) {}; };
}
Mutex mu_;
};
llvm-svn: 301916
The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form.
llvm-svn: 301891
If a file has no diagnostic pragmas, we build its diagnostic state lazily, but
in this case we never set up the root state to be the diagnostic state in which
the module was originally built, so the diagnostic flags for files in the
module with no diagnostic pragmas were incorrectly based on the user of the
module rather than the diagnostic state when the module was built.
llvm-svn: 301846
Do not spuriously reject constexpr functions that access elements of an array
of unknown bound; this may later become valid once the bound is known. Permit
array-to-pointer decay on such arrays, but disallow pointer arithmetic (since
we do not know whether it will have defined behavior).
The standard is not clear on how this should work, but this seems to be a
decent answer.
Patch by Robert Haberlach!
llvm-svn: 301822
Summary:
Unless I'm missing something, the DeferredGlobal struct's GV field is
unused, removing which makes the struct itself trivial.
Reviewers: rafael, chandlerc
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D32691
llvm-svn: 301789
CheckForIntOverflow used to implement a whitelist of top-level expressions to
send to the constant expression evaluator, which handled many more expressions
than the CheckForIntOverflow whitelist did.
llvm-svn: 301742
When computing the appropriate cv-qualifiers for the 'this' capture, we have to examine each enclosing lambda - but when using the FunctionScopeInfo stack we have to ensure that the lambda below (outer) is the decl-context of the closure-class of the current lambda.
https://bugs.llvm.org/show_bug.cgi?id=32831
llvm-svn: 301735
Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us with a problem:
there is no way to represent the expansion of a #include that imports a module
in the -E output for such languages. (We don't want to just leave it as a
#include because that requires the consumer of the preprocessed source to have
the same file system layout and include paths as the creator.)
This patch adds a new pragma:
#pragma clang module import MODULE.NAME.HERE
that imports a module, and changes -E and -frewrite-includes to use it when
rewriting a #include that maps to a module import. We don't make any attempt
to use a native language syntax import if one exists, to get more consistent
output. (If in the future, @import and #include have different semantics in
some way, the pragma will track the #include semantics.)
llvm-svn: 301725
A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects.
Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow.
llvm-svn: 301721
Since -gsplit-dwarf is specified on a backend compile (in ThinLTO
parlance) it isn't passed during the frontend compile (because no ELF
object/dwo file is produced then), yet the -fno-split-dwarf-inlining
value needs to be encoded in the LLVM DebugInfo metadata to have
effect...
So let it be specified & it'll be silently ignored if -gsplit-dwarf
isn't used in the end, otherwise it'll be used on a per-cu basis
depending on where it's specified in the frontend compile actions.
llvm-svn: 301684
creation that are const-qualified.
When a block captures an ObjC object pointer, clang retains the pointer
to prevent prematurely destroying the object the pointer points to
before the block is called or copied.
When the captured object pointer is const-qualified, we can avoid
emitting the retain/release pair since the pointer variable cannot be
modified in the scope in which the block literal is introduced.
For example:
void test(const id x) {
callee(^{ (void)x; });
}
This patch implements that optimization.
rdar://problem/28894510
Differential Revision: https://reviews.llvm.org/D32601
llvm-svn: 301667
- I removed doxygen comments for the intrinsics that "alias" the other existing documented intrinsics and that only sligtly differ in spelling (single underscores vs. double underscores).
#define _tzcnt_u16(a) (__tzcnt_u16((a)))
It will be very hard to keep the documentation for these "aliases" in sync with the documentation for the intrinsics they alias to. Out of sync documentation will be more confusing than no documentation.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 301652
action to the general FrontendAction infrastructure.
This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map
compilation. (The -E form is not currently especially useful yet as there's no
good way to take the output and use it to actually build a module.)
In order to support this, -cc1 now accepts -x <lang>-module-map in all cases
where it accepts -x <lang> for a language we can parse (not ir/ast). And for
uniformity, we also accept -x <lang>-header for all such languages (we used
to reject for cuda and renderscript), and -x <lang>-cpp-output for all such
languages (we used to reject for c, cl, and renderscript).
(None of these new alternatives are accepted by the driver yet, so no
user-visible changes.)
llvm-svn: 301610
Create a header and impl file for the structural equivalence context.
This is to allow other users outside clang importer. NFCI
Differential Revision: https://reviews.llvm.org/D31777
rdar://problem/30167717
llvm-svn: 301604
'adjustRemovals' is used to avoid situation when removing a range inadvertently causes 2 separate identifiers to get joined into one.
But it is not useful when the edits are character precise, as is the case with the remap files.
llvm-svn: 301602
One of the -Wincomplete-umbrella warnings diagnoses when a header is present in
the directory but it's not present in the umbrella header. Currently, this
warning only happens on top level modules; any submodule using an umbrella
header does not get this warning. Fix that by also considering the submodules.
Differential Revision: https://reviews.llvm.org/D32576
rdar://problem/22623686
llvm-svn: 301597
size_t is usually defined as unsigned long, but on 64-bit platforms,
stdint.h currently defines SIZE_MAX using "ull" (unsigned long long).
Although this is the same width, it doesn't necessarily have the same
alignment or calling convention. It also triggers printf warnings when
using the format flag "%zu" to print SIZE_MAX.
This changes SIZE_MAX to reuse the compiler-provided __SIZE_MAX__, and
provides similar fixes for the other integers:
- INTPTR_MIN
- INTPTR_MAX
- UINTPTR_MAX
- PTRDIFF_MIN
- PTRDIFF_MAX
- INTMAX_MIN
- INTMAX_MAX
- UINTMAX_MAX
- INTMAX_C()
- UINTMAX_C()
... and fixes the typedefs for intptr_t and uintptr_t to use
__INTPTR_TYPE__ and __UINTPTR_TYPE__ instead of int32_t, effectively
reverting r89224, r89226, and r89237 (r89221 already having been
effectively reverted).
We can probably also kill __INTPTR_WIDTH__, __INTMAX_WIDTH__, and
__UINTMAX_WIDTH__ in a follow-up, but I was hesitant to delete all the
per-target CHECK lines in this commit since those might serve their own
purpose.
rdar://problem/11811377
llvm-svn: 301593
If a file search involves a header map, suppress
-Wnonportable-include-path. It's firing lots of false positives for
framework authors internally, and it's not trivial to fix.
Consider a framework called "Foo" with a main (installed) framework header
"Foo/Foo.h". It's atypical for "Foo.h" to actually live inside a
directory called "Foo" in the source repository. Instead, the
build system generates a header map while building the framework.
If Foo.h lives at the top-level of the source repository (common), and
the git repo is called ssh://some.url/foo.git, then the header map will
have something like:
Foo/Foo.h -> /Users/myname/code/foo/Foo.h
where "/Users/myname/code/foo" is the clone of ssh://some.url/foo.git.
After #import <Foo/Foo.h>, the current implementation of
-Wnonportable-include-path will falsely assume that Foo.h was found in a
nonportable way, because of the name of the git clone (.../foo/Foo.h).
However, that directory name was not involved in the header search at
all.
This commit adds an extra parameter to Preprocessor::LookupFile and
HeaderSearch::LookupFile to track if the search used a header map,
making it easy to suppress the warning. Longer term, once we find a way
to avoid the false positive, we should turn the warning back on.
rdar://problem/28863903
llvm-svn: 301592
Clang warns that a profile is out-of-date if it can't find a profile
record for any function in a TU. This warning became noisy after llvm
started allowing dead-stripping of instrumented functions.
To fix this, this patch changes the existing profile out-of-date warning
(-Wprofile-instr-out-of-date) so that it only complains about mismatched
data. Further, it introduces a new, off-by-default warning about missing
function data (-Wprofile-instr-missing).
Differential Revision: https://reviews.llvm.org/D28867
llvm-svn: 301570
The UnknownPragmaHandlers added by DoPrintPreprocessedInput conflict with the
real PragmaHandlers from clang::Parser because they try to handle the same
#pragma directives. This makes it impossible to use a Preprocessor (that was
previously passed to DoPrintPreprocessedInput), as an Preprocessor for a
clang::Parser instance which is what we currently do in cling.
This patch removes the added UnknownPragmaHandler to avoid conflicts these
conflicts and leave the PragmaHandlers of the Preprocessors in a the same state
as before calling DoPrintPreprocessedInput.
Patch by Raphael Isemann (D32486)!
llvm-svn: 301563
Summary:
Previously, clang-format would accidentally parse an async function
declaration as a function expression, and thus not insert an unwrapped
line for async functions, causing subsequent functions to run into the
function:
async function f() {
x();
} function g() { ...
With this change, async functions get parsed as top level function
declarations and get their own unwrapped line context.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32590
llvm-svn: 301538
for iOS < 9 and OS X < 10.11 X86 targets
This commit adds a new error that disallows methods that have parameters/return
values with a vector type for some older X86 targets. This diagnostic is
needed because objc_msgSend doesn't support SIMD vector registers/return values
on X86 in iOS < 9 and OS X < 10.11. Note that we don't necessarily know if the
vector argument/return value will use a SIMD register, so instead we chose to
be conservative and prohibit all vector types.
rdar://21662309
Differential Revision: https://reviews.llvm.org/D28670
llvm-svn: 301532
Don't list deprecated -std= values (c++0x etc). Only produce one line of output
per standard, even if we know it by multiple names.
In passing, add missing -std=gnu++03 alias (supported by GCC), and add new
spelling '-std=cl1.0' for OpenCL 1.0 for consistency with the other values,
with the same meaning as the preexisting '-std=cl'.
llvm-svn: 301507
We already prohibited this in most cases (in r130710), but had some bugs in our
enforcement of this rule. Specifically, this prevents the following
combinations:
* -x c -std=clN.M, which would previously effectively act as if -x cl were
used, despite the input being a C source file. (-x cl -std=cNN continues
to be disallowed.)
* -x c++ -std=cuda, which would previously select C++98 + CUDA, despite that
not being a C++ standard. (-x cuda -std=c++NN is still permitted, and
selects CUDA with the given C++ standard as its base language.
-x cuda -std=cuda is still supported with the meaning of CUDA + C++98.)
* -x renderscript -std=c++NN, which would previously form a hybrid "C++ with
RenderScript extensions" language. We could support such a thing, but
shouldn't do so by accident.
llvm-svn: 301497
Fix the nullability-assign check so that it can handle assignments into
C++ structs. Previously, such assignments were not instrumented.
Testing: check-clang, check-ubsan, enabling the existing test in ObjC++
mode, and building some Apple frameworks with -fsanitize=nullability.
llvm-svn: 301482
This reverts commit r301449. It breaks the build with:
MacroPPCallbacks.h:114:50: error: non-virtual member function marked 'override' hides virtual member function
llvm-svn: 301469
Do not add an overload if the function doesn't have a prototype; this
can happen if, for instance, a misplaced/malformed call site is
considered like a declaration for recovery purposes.
rdar://problem/31306325
llvm-svn: 301453
Summary:
The PPCallbacks::MacroUndefined callback is currently insufficient for clients that need to track the MacroDirectives.
This patch adds an additional argument to PPCallbacks::MacroUndefined that is the undef MacroDirective.
Reviewers: bruno, manmanren
Reviewed By: bruno
Subscribers: nemanjai, cfe-commits
Differential Revision: https://reviews.llvm.org/D29923
llvm-svn: 301449
isMicrosoftMissingTypename() uses a Type pointer without first checking
that it's non-null. PR32750 reports a case where the pointer is in fact
null. This patch adds in a defensive check and a regression test.
Differential Revision: https://reviews.llvm.org/D32519
llvm-svn: 301420
If some function template is instantiated during handling of OpenMP
code, currently it may cause crash of compiler because of trying of
capturing variables in non-capturing function scopes. Patch fixes this
bug.
llvm-svn: 301416
blocks and lambdas
Prior to this commit Clang emitted the old "partial availability" warning for
expressions that referred to declarations that were not yet introduced in
blocks and lambdas that were not in a function/method. This commit ensures that
top-level blocks and lambdas use the new unguarded availability checks.
rdar://31835952
llvm-svn: 301409
function/block pointer properties
The commit r300981 allowed @param/@return commands for function/block
pointer property declarations. This meant that -Wdocumentation started warning
about @return that was used to document properties whose function/block type
returned void. However, prior to that commit, we allowed @return for all
property declarations, because it can be used to document the value that's
returned by the property getter. This commit restores the previous behaviour:
now the @return command can be used to document all properties without warnings.
rdar://24978538
llvm-svn: 301402
loc
Prior to this commit -Wdocumentation crashed when checking the @returns command
for declarations whose function/block pointer type included an attribute like
_Nullable.
rdar://31818195
llvm-svn: 301400
Summary:
Java and JavaScript support annotations and decorators, respectively, that use a leading "@" token. clang-format currently detects this as an Objective-C construct and applies special formatting, for example no whitespace around "=" operators. This change disables the distinction for Java and JavaScript, which leads to normal formatting of single line annotated and initialized properties.
Before:
class X {
@foo() bar=false;
}
After:
class X {
@foo() bar = false;
}
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32532
llvm-svn: 301399
Summary: In JavaScript/TypeScript, class member definitions that use modifiers can be subject to Automatic Semicolon Insertion (ASI). For example, "class X { get \n foo }" defines a property called "get" and a property called "foo", both with no type annotation. This change prevents wrapping after the modifier keywords (visibility modifiers, static, get and set) to prevent accidental ASI.
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32531
llvm-svn: 301397
Use definition from canonical decl when checking for designated
initializers. This is necessary since deserialization of a interface
might reuse the definition from the canonical one (see r281119).
rdar://problem/29360655
llvm-svn: 301382
It's possible to determine the alignment of an alloca at compile-time.
Use this information to skip emitting some runtime alignment checks.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of alignment checks we emit when
compiling X86ISelLowering.cpp. Here are the numbers from patched/unpatched
clangs based on r301361.
------------------------------------------
| Setup | # of alignment checks |
------------------------------------------
| unpatched, -O0 | 47195 |
| patched, -O0 | 30876 | (-34.6%)
------------------------------------------
llvm-svn: 301377
This change restores pre-r301225 behavior, where linker GC compatible global
instrumentation was used on COFF targets disregarding -f(no-)data-sections and/or
/Gw flags.
This instrumentation puts each global in a COMDAT with an ASan descriptor for that global.
It effectively enables -fdata-sections, but limits it to ASan-instrumented globals.
llvm-svn: 301374
Richard Smith