Bruno Ricci [Mon, 25 Mar 2019 17:08:51 +0000 (17:08 +0000)]
[Sema][NFCI] Don't allocate storage for the various CorrectionCandidateCallback unless we are going to do some typo correction
The various CorrectionCandidateCallbacks are currently heap-allocated
unconditionally. This was needed because of delayed typo correction.
However these allocations represent currently 15.4% of all allocations
(number of allocations) when parsing all of Boost (!), mostly because
of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes
and isCXXDeclarationSpecifier. Note that all of these callback objects
are small. Let's not do this.
Instead initially allocate the callback on the stack, and only do a
heap allocation if we are going to do some typo correction. Do this by:
1. Adding a clone function to each callback, which will do a polymorphic
clone of the callback. This clone function is required to be implemented
by every callback (of which there is a fair amount). Make sure this is
the case by making it pure virtual.
2. Use this clone function when we are going to try to correct a typo.
This additionally cut the time of -fsyntax-only on all of Boost by 0.5%
(not that much, but still something). No functional changes intended.
Brian Gesiak [Mon, 25 Mar 2019 00:53:10 +0000 (00:53 +0000)]
Un-revert "[coroutines][PR40978] Emit error for co_yield within catch block"
Summary:
https://reviews.llvm.org/D59076 added a new coroutine error that
prevented users from using 'co_await' or 'co_yield' within a exception
handler. However, it was reverted in https://reviews.llvm.org/rC356774
because it caused a regression in nested scopes in C++ catch statements,
as documented by https://bugs.llvm.org/show_bug.cgi?id=41171.
The issue was due to an incorrect use of a `clang::ParseScope`. To fix:
1. Add a regression test for catch statement parsing that mimics the bug
report from https://bugs.llvm.org/show_bug.cgi?id=41171.
2. Re-apply the coroutines error patch from
https://reviews.llvm.org/D59076, but this time with the correct
ParseScope behavior.
Hubert Tong [Sat, 23 Mar 2019 18:10:45 +0000 (18:10 +0000)]
libclang/CIndexer.cpp: Use loadquery() on AIX for path to library
Summary:
`dladdr` is not available on AIX. Similar functionality is presented
through `loadquery`. This patch replaces a use of `dladdr` with a
version based on `loadquery`.
Sylvestre Ledru [Sat, 23 Mar 2019 17:57:31 +0000 (17:57 +0000)]
Sync some doc changes ClangFormatStyleOptions.rst with doc comments in `Format.h`
Summary:
These changes were corrected directly in ClangFormatStyleOptions.rst (llvm-svn: 350192 and llvm-svn: 351976) but these sections can be produced automatically using `dump_format_style.py` so sync the corresponding doc comments in `Format.h` as well.
Paul Hoad [Sat, 23 Mar 2019 14:37:58 +0000 (14:37 +0000)]
Clang-format: add finer-grained options for putting all arguments on one line
Summary:
Add two new options,
AllowAllArgumentsOnNextLine and
AllowAllConstructorInitializersOnNextLine. These mirror the existing
AllowAllParametersOfDeclarationOnNextLine and allow me to support an
internal style guide where I work. I think this would be generally
useful, some have asked for it on stackoverflow:
James Y Knight [Fri, 22 Mar 2019 18:27:13 +0000 (18:27 +0000)]
IR: Support parsing numeric block ids, and emit them in textual output.
Just as as llvm IR supports explicitly specifying numeric value ids
for instructions, and emits them by default in textual output, now do
the same for blocks.
This is a slightly incompatible change in the textual IR format.
Previously, llvm would parse numeric labels as string names. E.g.
define void @f() {
br label %"55"
55:
ret void
}
defined a label *named* "55", even without needing to be quoted, while
the reference required quoting. Now, if you intend a block label which
looks like a value number to be a name, you must quote it in the
definition too (e.g. `"55":`).
Previously, llvm would print nameless blocks only as a comment, and
would omit it if there was no predecessor. This could cause confusion
for readers of the IR, just as unnamed instructions did prior to the
addition of "%5 = " syntax, back in 2008 (PR2480).
Now, it will always print a label for an unnamed block, with the
exception of the entry block. (IMO it may be better to print it for
the entry-block as well. However, that requires updating many more
tests.)
Thus, the following is supported, and is the canonical printing:
define i32 @f(i32, i32) {
%3 = add i32 %0, %1
br label %4
4:
ret i32 %3
}
New test cases covering this behavior are added, and other tests
updated as required.
Brian Gesiak [Fri, 22 Mar 2019 16:08:29 +0000 (16:08 +0000)]
Revert "[coroutines][PR40978] Emit error for co_yield within catch block"
The commit https://reviews.llvm.org/rC356296 is causing a regression in nested
catch scopes, https://bugs.llvm.org/show_bug.cgi?id=41171. Revert this change
for now in order to un-break that problem report.
Alexey Bataev [Fri, 22 Mar 2019 15:25:12 +0000 (15:25 +0000)]
[OPENMP]Allow no allocator clause in target regions with requires
dynamic_allocators.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit. Patch adds a check for a
presence of the requires directive with the dynamic_allocators clause.
Alexey Bataev [Fri, 22 Mar 2019 14:41:39 +0000 (14:41 +0000)]
[OPENMP]Emit error message for allocate directive without allocator
clause in target region.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit.
Roman Lebedev [Fri, 22 Mar 2019 13:40:36 +0000 (13:40 +0000)]
[AST] OMPStructuredBlockTest: avoid using multiline string literals in macros
That is what i have been doing elsewhere in these tests, maybe that's it?
Maybe this helps with failing builds:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/17921
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/10248
Amara Emerson [Thu, 21 Mar 2019 22:31:37 +0000 (22:31 +0000)]
[AArch64] Split the neon.addp intrinsic into integer and fp variants.
This is the result of discussions on the list about how to deal with intrinsics
which require codegen to disambiguate them via only the integer/fp overloads.
It causes problems for GlobalISel as some of that information is lost during
translation, while with other operations like IR instructions the information is
encoded into the instruction opcode.
This patch changes clang to emit the new faddp intrinsic if the vector operands
to the builtin have FP element types. LLVM IR AutoUpgrade has been taught to
upgrade existing calls to aarch64.neon.addp with fp vector arguments, and
we remove the workarounds introduced for GlobalISel in r355865.
Richard Smith [Thu, 21 Mar 2019 20:42:13 +0000 (20:42 +0000)]
Improve the diagnostic for #include_next occurring in a file not found
in the include path.
Instead of making the incorrect claim that the included file has an
absolute path, describe the actual problem: the including file was found
either by absolute path, or relative to such a file, or relative to the
primary source file.
Craig Topper [Thu, 21 Mar 2019 20:07:24 +0000 (20:07 +0000)]
[Driver] Pass -malign-double from the driver to the cc1 command line
-malign-double is currently only implemented in the -cc1 interface. But its declared in Options.td so it is a driver option too. But you try to use it with the driver you'll get a message about the option being unused.
This patch teaches the driver to pass the option through to cc1 so it won't be unused. The Options.td says the option is x86 only but I didn't see any x86 specific code in its impementation in cc1 so not sure if the documentation is wrong or if I should only pass this option through the driver on x86 targets.
Richard Smith [Thu, 21 Mar 2019 19:44:17 +0000 (19:44 +0000)]
Refactor handling of #include directives to cleanly separate the
"skipped header because it should be imported as a module" cases from
the "skipped header because of some other reason" cases.
Alexey Bataev [Thu, 21 Mar 2019 19:35:27 +0000 (19:35 +0000)]
[OPENMP]Codegen support for allocate directive on global variables.
For the global variables the allocate directive must specify only the
predefined allocator. This allocator must be translated into the correct
form of the address space for the targets that support different address
spaces.
Alexey Bataev [Thu, 21 Mar 2019 19:05:07 +0000 (19:05 +0000)]
[OPENMP]Simplify the check for the predefined allocators, NFC.
Previously implemented check required the reevaluation of the already
evaluated predefined allocator kind for the global variables. Patch
simplifies this evaluation and removes extra code.
Craig Topper [Thu, 21 Mar 2019 17:43:53 +0000 (17:43 +0000)]
[X86] Add __popcntd and __popcntq to ia32intrin.h to match gcc and icc. Remove popcnt feature flag from _popcnt32/_popcnt64 and move to ia32intrin.h to match gcc
gcc and icc both implement popcntd and popcntq which we did not. gcc doesn't seem to require a feature flag for the _popcnt32/_popcnt64 spelling and will use a libcall if its not supported.
Summary:
`OMPClause` is the base class, it is not descendant from **any**
other class, therefore for it to work with e.g.
`VariadicDynCastAllOfMatcher<>`, it needs to be handled here.
Erich Keane [Thu, 21 Mar 2019 13:30:56 +0000 (13:30 +0000)]
Permit redeclarations of a builtin to specify calling convention.
After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.
When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly. This patch ALSO
unifies those under a 'select'. Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.
Paul Hoad [Thu, 21 Mar 2019 13:09:22 +0000 (13:09 +0000)]
[clang-format] Add basic support for formatting C# files
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
This CL causes our creduce-clang-crash.py util to:
- try to preprocess the file before reducing
- try to remove some command line arguments
- now require a llvm bin directory, since the generated crash script
doesn't have an absolute path for clang
It also marks it as executable, since I forgot to do that in the last
commit. :)
Artem Dergachev [Thu, 21 Mar 2019 00:15:07 +0000 (00:15 +0000)]
[CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.
When searching for construction contexts, i.e. figuring out which statements
define the object that is constructed by each construct-expression, ignore
transparent init-list expressions because they don't add anything to the
context. This allows the Static Analyzer to model construction, destruction,
materialization, lifetime extension correctly in more cases. Also fixes
a crash caused by incorrectly evaluating initial values of variables
initialized with such expressions.
Jordan Rupprecht [Wed, 20 Mar 2019 21:01:56 +0000 (21:01 +0000)]
[clang][OpenMP] Fix build when using libgomp
Summary: rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp.
Alexey Bataev [Wed, 20 Mar 2019 20:14:22 +0000 (20:14 +0000)]
[OPENMP]Improve detection of omp_allocator_handle_t type and predefined
allocators.
It is better to deduce omp_allocator_handle_t type from the predefined
allocators, because omp.h header might not define it explicitly. Plus,
it allows to identify the predefined allocators correctly when trying to
build the allcoator for the global variables.
Erik Pilkington [Wed, 20 Mar 2019 19:26:33 +0000 (19:26 +0000)]
[Sema] Deduplicate some availability checking logic
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
Rafael Auler [Wed, 20 Mar 2019 19:22:24 +0000 (19:22 +0000)]
Recommit "Support attribute used in member funcs of class templates"
This diff previously exposed a bug in LLVM's IRLinker, breaking
buildbots that tried to self-host LLVM with monolithic LTO.
The bug is now in LLVM by D59552
Original commit message:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.
Raphael Isemann [Wed, 20 Mar 2019 19:00:25 +0000 (19:00 +0000)]
Remove the unused return value in ASTImporter::Imported [NFC]
Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.
Roman Lebedev [Wed, 20 Mar 2019 17:14:49 +0000 (17:14 +0000)]
[AST] Disable ast-dump-openmp-parallel-master-XFAIL.c test
Fails on MSVC buildbot (but not locally).
Not important as it is 'testing' something that isn't supported yet anyway:
https://bugs.llvm.org/show_bug.cgi?id=41022
[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))
Summary:
[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))
For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller
will try to fully unroll a loop unless the trip count is not known at compile time.
In that case for '.full' metadata no unrolling will be processed, while for '.enable'
the loop will be partially unrolled with a heuristically chosen unroll factor.
See: docs/LanguageExtensions.rst
From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html
__attribute__((opencl_unroll_hint))
for (int i=0; i<2; i++)
{
...
}
In the example above, the compiler will determine how much to unroll the loop.
Before the patch for __attribute__((opencl_unroll_hint)) was generated metadata
!{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how
much to unroll the loop.
For C/C++, an executable statement, possibly compound, with a single entry at the
top and a single exit at the bottom, or an OpenMP construct.
COMMENT: See Section 2.1 on page 38 for restrictions on structured
blocks.
```
```
2.1 Directive Format
Some executable directives include a structured block. A structured block:
• may contain infinite loops where the point of exit is never reached;
• may halt due to an IEEE exception;
• may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
_Noreturn specifier (in C) or a noreturn attribute (in C/C++);
• may be an expression statement, iteration statement, selection statement, or try block, provided
that the corresponding compound statement obtained by enclosing it in { and } would be a
structured block; and
Restrictions
Restrictions to structured blocks are as follows:
• Entry to a structured block must not be the result of a branch.
• The point of exit cannot be a branch out of the structured block.
C / C++
• The point of entry to a structured block must not be a call to setjmp().
• longjmp() and throw() must not violate the entry/exit criteria.
```
Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`,
in the same sense as with the normal `noexcept` functions in C++.
I.e. if throw happens, and it attempts to travel out of the `noexcept` function
(here: out of the current structured-block), then the program terminates.
Now, one of course can say that since it is explicitly prohibited by the Specification,
then any and all programs that violate this Specification contain undefined behavior,
and are unspecified, and thus no one should care about them. Just don't write broken code /s
But i'm not sure this is a reasonable approach.
I have personally had oss-fuzz issues of this origin - exception thrown inside
of an OpenMP structured-block that is not caught, thus causing program termination.
This issue isn't all that hard to catch, it's not any particularly different from
diagnosing the same situation with the normal `noexcept` function.
Now, clang static analyzer does not presently model exceptions.
But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check,
and it is even refactored as a `ExceptionAnalyzer` class for reuse.
So it would be trivial to use that analyzer to check for
exceptions escaping out of OpenMP structured blocks. (D59466)
All that sounds too great to be true. Indeed, there is a caveat.
Presently, it's practically impossible to do. To check a OpenMP structured block
you need to somehow 'get' the OpenMP structured block, and you can't because
it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation.
Now, it is of course possible to write e.g. some AST matcher that would e.g.
match every OpenMP executable directive, and then return the whatever `Stmt` is
the structured block of said executable directive, if any.
But i said //practically//. This isn't practical for the following reasons:
1. This **will** bitrot. That matcher will need to be kept up-to-date,
and refreshed with every new OpenMP spec version.
2. Every single piece of code that would want that knowledge would need to
have such matcher. Well, okay, if it is an AST matcher, it could be shared.
But then you still have `RecursiveASTVisitor` and friends.
`2 > 1`, so now you have code duplication.
So it would be reasonable (and is fully within clang AST spirit) to not
force every single consumer to do that work, but instead store that knowledge
in the correct, and appropriate place - AST, class structure.
Now, there is another hoop we need to get through.
It isn't fully obvious //how// to model this.
The best solution would of course be to simply add a `OMPStructuredBlock` transparent
node. It would be optimal, it would give us two properties:
* Given this `OMPExecutableDirective`, what's it OpenMP structured block?
* It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`)
But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`.
(even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween).
So i'm not sure whether or not we could re-create AST statements after they were already created?
There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12
```
1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity.
2. You will need to support serialization/deserialization.
3. You will need to support template instantiation.
4. You will need to support codegen and take this new construct to account in each OpenMP directive.
```
Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts.
Part 1:
* Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class,
that will tell whether this directive is stand-alone or not, as per the spec.
We need it because we can't just check for the existance of associated statements,
see code comment.
* Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself,
that assert that this is not a stand-alone directive, and either return the correct loop body
if this is a loop-like directive, or the captured statement.
This way, given an `OMPExecutableDirective`, we can get it's structured block.
Also, since the knowledge is ingrained into the clang OpenMP implementation,
it will not cause any duplication, and //hopefully// won't bitrot.
Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach.
Thus, there is a second part needed:
* How can we check whether a given `Stmt*` is `OMPStructuredBlock`?
Well, we can't really, in general. I can see this workaround:
```
class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> {
using Base = RecursiveASTVisitor<FunctionASTVisitor>;
public:
bool VisitOMPExecDir(OMPExecDir *D) {
OmpStructuredStmts.emplace_back(D.getStructuredStmt());
}
bool VisitSOMETHINGELSE(???) {
if(InOmpStructuredStmt)
HI!
}
bool TraverseStmt(Stmt *Node) {
if (!Node)
return Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node)
++InOmpStructuredStmt;
Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node) {
OmpStructuredStmts.pop_back();
--InOmpStructuredStmt;
}
return true;
}
std::vector<Stmt*> OmpStructuredStmts;
int InOmpStructuredStmt = 0;
};
```
But i really don't see using it in practice.
It's just too intrusive; and again, requires knowledge duplication.
.. but no. The solution lies right on the ground.
Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself?
This does not appear to have any impact on the memory footprint of the clang AST,
since it's just a single extra bit in the bitfield. At least the static assertions don't fail.
Thus, indeed, we can achieve both of the properties without a new AST node.
We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`,
by just calling the `getStructuredBlock()` that we just added.
Test coverage that demonstrates all this has been added.
This isn't as great with serialization though. Most of it does not use abbrevs,
so we do end up paying the full price (4 bytes?) instead of a single bit.
That price, of course, can be reclaimed by using abbrevs.
In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly.
I'm not seeing a third solution. If there is one, it would be interesting to hear about it.
("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.)
Balazs Keri [Wed, 20 Mar 2019 15:42:42 +0000 (15:42 +0000)]
[ASTImporter] Remove obsolete function ImportTemplateParameterList.
Summary:
The ASTNodeImporter::ImportTemplateParameterList is replaced by a
template specialization of 'import' that already exists and does
(almost) the same thing.
Craig Topper [Wed, 20 Mar 2019 07:31:18 +0000 (07:31 +0000)]
[X86] Separate PentiumPro and i686. They aren't aliases in the backend.
PentiumPro has HasNOPL set in the backend. i686 does not.
Despite having a function that looks like it canonicalizes alias names. It
doesn't seem to be called. So I don't think this is a functional change. But its
good to be consistent between the backend and frontend.
Erik Pilkington [Tue, 19 Mar 2019 20:44:18 +0000 (20:44 +0000)]
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size
The attribute pass_dynamic_object_size(n) behaves exactly like
pass_object_size(n), but instead of evaluating __builtin_object_size on calls,
it evaluates __builtin_dynamic_object_size, which has the potential to produce
runtime code when the object size can't be determined statically.
Alexey Bataev [Tue, 19 Mar 2019 20:33:44 +0000 (20:33 +0000)]
[OPENMP]Warn if the different allocator is used for the variable.
If the allocator was specified for the variable and next one is found
with the different allocator, the warning is emitted, and the allocator
is ignored.
Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib= [take 2]
"clang++ hello.cc --rtlib=compiler-rt"
now can works without specifying additional unwind or exception
handling libraries.
This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.
This should address the issues from the previous version.
Alexey Bataev [Tue, 19 Mar 2019 18:39:11 +0000 (18:39 +0000)]
[OPENMP]Check that global vars require predefined allocator.
According to OpenMP, 2.11.3 allocate Directive, Restrictions, C / C++,
if a list item has a static storage type, the allocator expression in
the allocator clause must be a constant expression that evaluates to
one of the predefined memory allocator values. Added check for this
restriction.
[Sema] Adjust addr space of reference operand in compound assignment
When we create overloads for the builtin compound assignment operators
we need to preserve address space for the reference operand taking it
from the argument that is passed in.
Alexey Bataev [Tue, 19 Mar 2019 16:41:16 +0000 (16:41 +0000)]
[OPENMP] Codegen for local variables with the allocate pragma.
Added initial codegen for the local variables with the #pragma omp
allocate directive. Instead of allocating the variables on the stack,
__kmpc_alloc|__kmpc_free functions are used for memory (de-)allocation.
Gabor Marton [Tue, 19 Mar 2019 14:04:50 +0000 (14:04 +0000)]
[ASTImporter] Fix redecl failures of FunctionTemplateSpec
Summary:
Redecl chains of function template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Gabor Marton [Tue, 19 Mar 2019 13:34:10 +0000 (13:34 +0000)]
[ASTImporter] Fix redecl failures of ClassTemplateSpec
Summary:
Redecl chains of class template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Private fields and methods in JavaScript would get incorrectly indented
(it sees them as preprocessor directives and hence left aligns them)
In this revision `#identifier` tokens `tok::hash->tok::identifier` are
merged into a single new token `tok::identifier` with the `#` contained
inside the TokenText.
NOTE: There might be some JavaScript code out there which uses the C
processor to preprocess .js files
http://www.nongnu.org/espresso/js-cpp.html. It's not clear how this
revision or even private fields and methods would interact.
Martin Probst [Tue, 19 Mar 2019 11:15:52 +0000 (11:15 +0000)]
[clang-format] [JS] Don't break between template string and tag
Before:
const x = veryLongIdentifier
`hello`;
After:
const x =
veryLongIdentifier`hello`;
While it's allowed to have the template string and tag identifier
separated by a line break, currently the clang-format output is not
stable when a break is forced. Additionally, disallowing a line break
makes it clear that the identifier is actually a tag for a template
string.
Eric Liu [Tue, 19 Mar 2019 10:12:15 +0000 (10:12 +0000)]
[Tooling] Add more scope specifiers until spelling is not ambiguous.
Summary:
Previously, when the renamed spelling is ambiguous, we simply use the
full-qualfied name (with leading "::"). This patch makes it try adding
additional specifiers one at a time until name is no longer ambiguous,
which allows us to find better disambuguated spelling.
Don Hinton [Tue, 19 Mar 2019 06:14:14 +0000 (06:14 +0000)]
Refactor cast<>'s in if conditionals, which can only assert on failure.
Summary:
This patch refactors several instances of cast<> used in if
conditionals. Since cast<> asserts on failure, the else branch can
never be taken.
In some cases, the fix is to replace cast<> with dyn_cast<>. While
others required the removal of the conditional and some minor
refactoring.
A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html
Richard Smith [Tue, 19 Mar 2019 01:51:19 +0000 (01:51 +0000)]
Factor out repeated code parsing and concatenating header-names from
tokens.
We now actually form an angled_string_literal token for a header name by
concatenation rather than just working out what its contents would be.
This substantially simplifies downstream processing and is necessary for
C++20 header unit imports.
projects / clang / log