| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansions by calling getSpellingLoc(). That's great in most cases, but for
macros defined in the '<built-in>' source file, the source file is invalid
and does not import correctly, causing an assertion failure (the assertion
is Invalid SLocOffset or bad function choice).
A more reliable way to avoid this is to use getFileLoc(), which does not
return built-in locations. This avoids the crash but still preserves valid
source locations.
I've added a testcase that covers the previously crashing scenario.
https://reviews.llvm.org/D26054
llvm-svn: 286144
|
| |
|
|
| |
llvm-svn: 286132
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constructs.
For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but not the
underlying builtin integer or float type. This causes crash in codegen
for atomic constructs, if __real/__imag expression are used in atomic
constructs.
llvm-svn: 286129
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The fixed code is basically identical to the same loop below, which
might indicate an opportunity for refactoring. I just wanted to fix
the use-of-temporary issue.
Caught by adding a similar check to StringRef as r283798 did for
ArrayRef. I'll be upstreaming that soon.
Reviewed by Vedant Kumar as https://reviews.llvm.org/D26317.
llvm-svn: 286122
|
| |
|
|
| |
llvm-svn: 286121
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26302
llvm-svn: 286114
|
| |
|
|
| |
llvm-svn: 286106
|
| |
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286103
|
| |
|
|
|
|
|
| |
This reverts commit r286098 because the modified test breaks on many of the
buildbots.
llvm-svn: 286102
|
| |
|
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP
regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286098
|
| |
|
|
|
|
| |
embedded rounding control arguments.
llvm-svn: 286097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current version does not deduplicate equivalent file paths correctly.
For example, a relative path and an absolute path are considered inequivalent.
Comparing FileEnry addresses these issues.
Reviewers: djasper
Subscribers: alexshap, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26288
llvm-svn: 286096
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaaaaaaa<
aaaaaaaaa, aaaaaaaaaa,
aaaaaaaaaaaaaa><<<aaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaaaaaaaaa>>>();
After:
aaaaaaaaaaaaaaa<aaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaaaaa>
<<<aaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaaaaaaaaa>>>();
llvm-svn: 286041
|
| |
|
|
| |
llvm-svn: 285994
|
| |
|
|
|
|
| |
CXCursor_FriendDecl was added in r285984
llvm-svn: 285986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which guarantee pointers are not null. These all seem to have useful
properties and correlations to document, in one case we even had it in
a comment but now it will also be an assert.
This should prevent PVS-Studio from incorrectly claiming that there are
a bunch of potential bugs here. But I feel really strongly that the
PVS-Studio warnings that pointed at this code have a far too high
false-positive rate to be entirely useful. These are just places where
there did seem to be a useful invariant to document and verify with an
assert. Several other places in the code were already correct and
already have perfectly clear code documenting and validating their
invariants, but still ran afoul of PVS-Studio.
llvm-svn: 285985
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26285
llvm-svn: 285984
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The exact same test guards entry into the loop in which this test
occurs, and there is nothing inside the loop that assigns to the
variable, so it has already been checked for null.
This was flagged by PVS-Studio as well, but the report is actually wrong
-- this is not a case where we dereference a variable prior to testing
it for null, this is a case where we have a redundant test for null
after we already performed the exact same test.
llvm-svn: 285983
|
| |
|
|
|
|
|
|
|
|
|
| |
corresponds to another argument being valid.
This makes it clear that the code is correct despite the PVS-Studio
report that a pointer might be dereferenced prior to being checked for
whether it is null. It likely is also enough for static analyzers to not
flag the code.
llvm-svn: 285982
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Present tests for the functionality provided by command lime option
`-ast-print` check only absence of crash. This change tries to make
testing better, - the output produced by the compiler is compiled again
with option `-print-ast` and both outputs are compared. Such test at
least checks that the output is valid code. This change fixes only the
test for pure C.
This is recommit of r285882.
llvm-svn: 285981
|
| |
|
|
|
|
|
|
|
|
|
|
| |
dereferenced the pointer at this point, and these routines are
exclusively called after the parser encounters a code completion token.
Other code completion routines called at that point do not check for
null either, so this is clearly the current invariant expected in the
code.
This fixes another PVS-Studio found issue.
llvm-svn: 285980
|
| |
|
|
|
|
|
| |
Output generated by option '-ast-print' must not contains enum
base type specifications if source language does not include C++11.
llvm-svn: 285979
|
| |
|
|
| |
llvm-svn: 285971
|
| |
|
|
|
|
| |
<rdar://problem/18616046>
llvm-svn: 285960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* if the base is produced by a series of derived-to-base conversions, check
the expression inside them when looking for an expression with a known
dynamic type
* step past MaterializeTemporaryExprs when checking for a known dynamic type
* when checking for a known dynamic type, treat all class prvalues as having
a known dynamic type after skipping all relevant rvalue subobject
adjustments
* treat callees formed by pointer-to-member access for a non-reference member
type like callees formed by member access.
llvm-svn: 285954
|
| |
|
|
|
|
|
|
|
|
|
|
| |
code, let's just assert that the DiagonsticEngine doesn't own the client
because our constructor took ownership of it and has a std::unique_ptr
that handles deleting it. This seems much more clear -- the release was
harmless but confusing as if there were some memory there it would have
leaked, and the reset was harmless but confusing as if there were some
memory there it would have been double-freed. But in both cases there
was nothing there.
llvm-svn: 285950
|
| |
|
|
|
|
|
|
| |
that its result is in fact used. Instead, use reset.
This was pointed out by PVS-Studio.
llvm-svn: 285946
|
| |
|
|
| |
llvm-svn: 285938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
During clang-format source lexing >> and << operators are split and
treated as two less/greater operators but column position of following
tokens was not adjusted accordingly.
Fixes PR26887
Patch by Paweł Żukowski.
Reviewers: djasper
Subscribers: malcolm.parsons, mprobst, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D25439
llvm-svn: 285934
|
| |
|
|
|
|
|
|
| |
ConstructJobMultipleOutputs.
It was causing trouble with the GCC bots.
llvm-svn: 285925
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and FatalErrorOccurred are both set.
This fixes a crash that occurs when a warning promoted to a fatal error
leaves the AST in an incomplete state, and then later CFG analysis is
run on the incomplete AST.
rdar://problem/28558923
Differential Revision: https://reviews.llvm.org/D26166
llvm-svn: 285923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Python bindings tests now pass in Python 3.
`map` in Python 3 is lazily evaluated so the method by which functions are registered needed updating.
Strings are unicode in Python 3 not UTF-8, I've tried to create an new c_types-like class (c_string_p) to automate the conversion.
String conversions made explicit where required.
Reviewers: eliben, nemanjai, skalinichev, compnerd
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D26082
llvm-svn: 285909
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: aaron.ballman, mehdi_amini, dblaikie
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26276
llvm-svn: 285899
|
| |
|
|
|
|
| |
It broke buildbot on Windows.
llvm-svn: 285889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use better heuristics to detect if a '{' might be the start of the constructor body
or not. Especially when there is a completion token.
Fix the test 'test/CodeCompletion/ctor-initializer.cpp ' when clang defaults to c++11
The problem was is how we recover invalid code in the ctor-init part as we skip the
function body. In particular, we want to know if a '{' is the begining of the body.
In C++03, we always consider it as the beginng of the body. The problem was that in
C++11, it may be the start of an initializer, so we skip over it, causing further
parse errors later. (It is important that we are able to parse correctly the rest
of the class definition, to know what are the class member, for example)
This commit is improving the heuristics to decide if the '{' is starting a function
body. The rules are the following: If we are not in a template argument, and that the
previous tokens are not an identifier, or a >, then it is much more likely to be the
function body. We verify that further by checking the token after the matching '}'
The commit also fix the behavior when there is a code_completion token in the
ctor-initializers.
Differential Revision: https://reviews.llvm.org/D21502
llvm-svn: 285883
|
| |
|
|
|
|
|
|
|
|
|
| |
Present tests for the functionality provided by command lime option
`-ast-print` check only absence of crash. This change tries to make
testing better, - the output produced by the compiler is compiled again
with option `-print-ast` and both outputs are compared. Such test at
least checks that the output is valid code. This change fixes only the
test for pure C.
llvm-svn: 285882
|
| |
|
|
|
|
|
|
|
|
|
| |
The assignment to NextIsDereference is either followed by (1) another,
unrelated assignment to NextIsDereference or by (2) an early loop exit.
Found by clang's static analyzer: http://llvm.org/reports/scan-build
(While we're at it fix a typo.)
llvm-svn: 285879
|
| |
|
|
|
|
|
|
| |
Looks like CurFn's name outlives FunctionName, so we can just pass
StringRefs around rather than going from a StringRef to a std::string
to a const char* to a StringRef.
llvm-svn: 285873
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-reference-related types.
Summary:
[expr.cast.static] states:
> 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible
> with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is
> an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is
> ill-formed.
>
> 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_-
> cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...]
Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases. For example:
```
double y = 42;
static_cast<int&&>(y); // this should be OK. 'int&& t(y)' is well formed
```
Note that we still don't check p4 for non-reference-compatible types which are reference-related since `T&& t(e);` should never be well formed in those cases.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26231
llvm-svn: 285872
|
| |
|
|
|
|
| |
proposal on cxx-abi-dev earlier today.
llvm-svn: 285870
|
| |
|
|
|
|
| |
clang-query's dumping functionality. =(
llvm-svn: 285869
|
| |
|
|
|
|
|
|
|
|
|
| |
new' function.
Part of this is to allow creating a USR for the canonical decl of that which is implicit and does
not have a source location.
rdar://28978992
llvm-svn: 285868
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the following code would warn on the use of "T":
template <typename T>
struct X {
typedef T *type;
};
...because nullability is /allowed/ on template parameters (because
they could be pointers). (Actually putting nullability on this use of
'T' will of course break if the argument is a non-pointer type.)
This fix doesn't handle the case where a template parameter is used
/outside/ of a typedef. That seems trickier, especially in parameter
position.
llvm-svn: 285856
|
| |
|
|
|
|
|
|
|
|
| |
Because standard functions can be defined differently on different platforms,
this commit introduces a method for constructing summaries with multiple
variants, whichever matches better. It is also useful for supporting overloads.
Differential Revision: https://reviews.llvm.org/D25940
llvm-svn: 285852
|
| |
|
|
|
|
|
|
|
|
| |
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
|
| |
|
|
|
|
|
|
|
| |
This commit simplifies and clarifies the test code
that was added in r285289.
Suggested by David Blaikie.
llvm-svn: 285825
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
llvm-svn: 285823
|
| |
|
|
|
|
|
|
|
|
| |
-shared-libasan is likely to be used as a link flag if the user is using
the GCC-style clang driver.
This logic is already tested in clang-cl tests, and the new flag to
exercise it will be covered by asan tests.
llvm-svn: 285820
|
| |
|
|
|
|
| |
bumping up against that limit with MSVC 2015 in Win64 debug build mode.
llvm-svn: 285810
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: aaron.ballman, mehdi_amini, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26206
llvm-svn: 285799
|