| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promise_type
Summary: Now we helpfully provide a note pointing at the promise_type in question.
Reviewers: EricWF, GorNishanov
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33481
llvm-svn: 303752
|
|
|
|
|
|
| |
rdar://32376363
llvm-svn: 303751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now FixedCompilationDatabase::loadFromCommandLine has no means to report
which error occurred if it fails to create compilation object. This is
a block for implementing D33013, because after that change driver will
refuse to create compilation if command line contains erroneous options.
This change adds additional argument to loadFromCommandLine, which is
assigned error message text if compilation object was not created. This is
the same way as other methods of CompilationDatabase report failure.
Differential Revision: https://reviews.llvm.org/D33272
llvm-svn: 303741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
|
|
|
|
| |
llvm-svn: 303734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change allows us to add arg1 logging support to functions through
the special case list provided through -fxray-always-instrument=. This
is useful for adding arg1 logging to functions that are either in
headers that users don't have control over (i.e. cannot change the
source) or would rather not do.
It only takes effect when the pattern is matched through the "fun:"
special case, as a category. As in:
fun:*pattern=arg1
Reviewers: pelikan, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33392
llvm-svn: 303719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sema creates a declaration for gro variable as:
auto $gro = $promise.get_return_object();
However, gro variable has to outlive coroutine frame and coroutine promise, but,
it can only be initialized after the coroutine promise was created, thus, we
split its emission in two parts: EmitGroAlloca emits an alloca and sets up
the cleanups. Later when the coroutine promise is available we initialize
the gro and set the flag that the cleanup is now active.
Duplicate of: https://reviews.llvm.org/D31670 (which arc patch refuses to apply for some reason)
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D33477
llvm-svn: 303716
|
|
|
|
|
|
| |
FinalBB need to be emitted even when unused to make sure it is deleted
llvm-svn: 303714
|
|
|
|
|
|
| |
__has_feature(attribute_diagnose_if_objc) for consistency with rest of attribute checks.
llvm-svn: 303713
|
|
|
|
|
|
|
|
| |
and properties as well
This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
llvm-svn: 303712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currenltly assert when want to diagnose a missing import and the decl
in question is already visible. It turns out that the decl in question
might be visible because another decl from the same module actually made
the module visible in a previous error diagnostic.
Remove the assertion and avoid re-exporting the module if it's already
visible.
rdar://problem/27975402
Differential Revision: https://reviews.llvm.org/D32828
llvm-svn: 303705
|
|
|
|
|
|
|
|
|
|
|
| |
being visible with its owning module if we're not tracking owning modules for
local declarations.
This avoids the possibility of a declaration being (meaninglessly) marked as
hidden with no owning module, which would otherwise lead to violated AST
invariants (checked by the added assertion).
llvm-svn: 303699
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
|
|
|
|
|
|
| |
Found by msan!
llvm-svn: 303686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
|
|
|
|
| |
llvm-svn: 303653
|
|
|
|
|
|
|
|
|
| |
from template instantiations should refer to the enum constant in the pattern
enum in the base template
rdar://32325459
llvm-svn: 303651
|
|
|
|
|
|
|
|
| |
refer to the pattern member enum in the base template
rdar://32325459
llvm-svn: 303650
|
|
|
|
| |
llvm-svn: 303649
|
|
|
|
|
|
|
|
|
| |
instantiations should refer to the pattern type aliases / typedefs in the base
templates
rdar://32325459
llvm-svn: 303648
|
|
|
|
|
|
|
|
| |
should refer to the pattern fields in the nested records in the base templates
rdar://32352429
llvm-svn: 303647
|
|
|
|
|
|
|
|
| |
to the pattern records in the base templates
rdar://32325459
llvm-svn: 303646
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change requires opencl triple environment for compiling OpenCL
program, which causes regressions in libclc.
This patch fixes that. Instead of deducing language based on triple
environment, it checks LangOptions.
Differential Revision: https://reviews.llvm.org/D33445
llvm-svn: 303644
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bkramer, krasimir, arphaman, akyrtzi
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33397
llvm-svn: 303630
|
|
|
|
|
|
| |
https://reviews.llvm.org/D31627
llvm-svn: 303605
|
|
|
|
| |
llvm-svn: 303604
|
|
|
|
|
|
| |
https://reviews.llvm.org/D31608
llvm-svn: 303603
|
|
|
|
|
|
|
|
|
|
| |
Wrap deallocation code with:
if (auto *mem = coro.free()) Deallocate
When backend decides to elide allocations it will replace coro.free with nullptr to suppress deallocation code.
llvm-svn: 303599
|
|
|
|
|
|
|
|
| |
SemaCoroutine forms expressions referring to the coroutine frame of the enclosing coroutine using coro.frame builtin.
During codegen, we emit llvm.coro.begin intrinsic that returns the address of the coroutine frame.
When coro.frame is emitted, we replace it with SSA value of coro.begin.
llvm-svn: 303598
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We wrap allocation code so that backend can elide it if necessary.
llvm.coro.alloc intrinsic returns true, when allocation is needed and false otherwise.
```
%NeedAlloc = call i1 @llvm.coro.alloc(token %2)
br i1 %NeedAlloc, label %AllocBB, label %InitBB
AllocBB:
%5 = call i64 @llvm.coro.size.i64()
%call = call i8* @_Znwm(i64 %5) ; operator new
br label %InitBB
InitBB:
%Phi = phi i8* [ null, %0 ], [ %call, %4 ]
call i8* @llvm.coro.begin(token %2, i8* %Phi)
```
Reviewers: majnemer, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31584
llvm-svn: 303596
|
|
|
|
|
|
|
|
|
|
| |
A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap.
https://reviews.llvm.org/D31414
Thanks to Aaron B for the review!
llvm-svn: 303594
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a diagnostic includes a highlighted range spanning multiple lines, clang
now supports printing out multiple lines of context if necessary to show the
highlighted ranges. This is not yet exposed in the driver, but can be enabled
by "-Xclang -fcaret-diagnostics-max-lines -Xclang N".
This is experimental until we can find out whether it works well in practice,
and if so, what a good default for the maximum number of lines is.
llvm-svn: 303589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If unhandled_exception member function is present in the coroutine promise,
wrap the body of the coroutine in:
```
try {
body
} catch(...) { promise.unhandled_exception(); }
```
Reviewers: EricWF, rnk, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31692
llvm-svn: 303583
|
|
|
|
|
|
|
|
|
|
| |
This allows #line directives to appear in system headers that have code
that clang would normally warn on. This is compatible with GCC, which is
easy to test by running `gcc -E`.
Fixes PR30752
llvm-svn: 303582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
1. build declaration of the gro local variable that keeps the result of get_return_object.
2. build return statement returning the gro variable
3. emit them during CodeGen
4. sema and CodeGen tests updated
Reviewers: EricWF, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31646
llvm-svn: 303573
|
|
|
|
|
|
| |
rdar://32323724
llvm-svn: 303568
|
|
|
|
|
|
| |
rdar://32323386
llvm-svn: 303563
|
|
|
|
|
|
|
|
| |
wrong location
Differential revision: https://reviews.llvm.org/D33250
llvm-svn: 303562
|
|
|
|
|
|
| |
rdar://32323315
llvm-svn: 303559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change that enabled wrapping at the previous scope's indentation had
unintended side-effects in that clang-format would prefer to wrap
closing parentheses to the next line if it avoided a wrap on the next
line (assuming very narrow lines):
fooObject
.someCall(barbazbam)
.then(bam);
Would get formatted as:
fooObject.someCall(barbazbam
).then(bam);
Because the ')' is now indented at the parent level (fooObject).
Normally formatting a builder pattern style call sequence like that is
outlawed in clang-format anyway. However for JavaScript this is special
cased to support trailing .bind calls.
This change disallows this special case when following a closing ')' to
avoid the problem.
Included are some random comment fixes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33399
llvm-svn: 303557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch prevents reflowing bullet lists in block comments.
It handles all lists supported by doxygen and markdown, e.g. bullet
lists starting with '-', '*', '+', as well as numbered lists starting
with -# or a number followed by a dot.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33285
llvm-svn: 303556
|
|
|
|
|
|
|
|
| |
the reference to the namespace
rdar://32323190
llvm-svn: 303555
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the `micromips` and `nomicromips` attributes
for MIPS targets.
Differential revision: https://reviews.llvm.org/D33363
llvm-svn: 303546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following section comments
Summary:
r303415 changed the way a sequence of line comments following a preprocessor
macro is handled, which has the unfortunate effect of aligning a trailing
preprocessor line comment and following unrelated section comments, so:
```
#ifdef A // comment about A
// section comment
#endif
```
gets turned into:
```
#ifdef A // comment about A
// section comment
#endif
```
This patch fixes this by additionally checking the original start columns of
the line comments.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33394
llvm-svn: 303541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
|
|
|
|
|
|
| |
from gcc.
llvm-svn: 303501
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)
Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.
For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}
See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627
In summary (and reiteration), the fix is as follows:
- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.
See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.
Thanks Richard!
llvm-svn: 303492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To not break LTO with different optimizations levels, we should insert
the barrier regardles of optimization level.
Reviewers: rjmccall, rsmith, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D32401
llvm-svn: 303488
|
|
|
|
|
|
|
|
|
| |
source symbols
Patch by Nathan Hawes.
https://reviews.llvm.org/D33346
llvm-svn: 303484
|
|
|
|
|
|
|
| |
describe what they're for, not how they do it, and factor out a bit more
common code into them.
llvm-svn: 303479
|