That variable was of type DenseMap<StringRef, unsigned>, but the
unsigned numbers needed to be monotonicly increasing numbers because
the implementation that used the variable depended on that fact.
That was an implementation detail and shouldn't have leaked into Config.
This patch simplifies its type to std::vector<StringRef>.
llvm-svn: 290151
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
Differential Revision: https://reviews.llvm.org/D14274
llvm-svn: 290149
* In C++, never create a FunctionNoProtoType for a builtin (fixes C++1z
crasher from r289754).
* Fix type of __sync_synchronize to be a no-parameter function rather than a
varargs function. This matches GCC.
* Fix type of vfprintf to match its actual type. We gave it a wrong type due
to PR4290 (apparently autoconf generates invalid code and expects compilers
to choke it down or it miscompiles the program; the relevant error in clang
was downgraded to a warning in r122744 to fix other occurrences of this
autoconf brokenness, so we don't need this workaround any more).
* Turn off vararg argument checking for __noop, since it's not *really* a
varargs function. Alternatively we could add custom type checking for it
and synthesize parameter types matching the actual arguments in each call,
but that seemed like overkill.
llvm-svn: 290146
Just the minimal support to get it working at the moment.
Includes checks for test/CodeGen/ARM/vzip.ll as an example.
Differential Revision: https://reviews.llvm.org/D27829
llvm-svn: 290144
gtest is a widely-used unit-testing API. It provides macros for unit test
assertions:
ASSERT_TRUE(p != nullptr);
that expand into an if statement that constructs an object representing
the result of the assertion and returns when the assertion is false:
if (AssertionResult gtest_ar_ = AssertionResult(p == nullptr))
;
else
return ...;
Unfortunately, the analyzer does not model the effect of the constructor
precisely because (1) the copy constructor implementation is missing from the
the header (so it can't be inlined) and (2) the boolean-argument constructor
is constructed into a temporary (so the analyzer decides not to inline it since
it doesn't reliably call temporary destructors right now).
This results in false positives because the analyzer does not realize that the
the assertion must hold along the non-return path.
This commit addresses the false positives by explicitly modeling the effects
of the two un-inlined constructors on the AssertionResult state.
I've added a new package, "apiModeling", for these kinds of checkers that
model APIs but don't emit any diagnostics. I envision all the checkers in
this package always being on by default.
This addresses the false positives reported in PR30936.
Differential Revision: https://reviews.llvm.org/D27773
rdar://problem/22705813
llvm-svn: 290143
The newly-added notes from r290132 are too noisy even when the fix-it
is valid. For the existing warning from r286521, it's probably the
right decision 95% of the time to put the change outside the macro if
the array is outside the macro and inside otherwise, but I don't want
to overthink it right now.
Caught by the ASan bot!
More rdar://problem/29524992
llvm-svn: 290141
The analyzer's CFG currently doesn't have nodes for calls to temporary
destructors. This causes the analyzer to explore infeasible paths in which
a no-return destructor would have stopped exploration and so results in false
positives when no-return destructors are used to implement assertions.
To mitigate these false positives, this patch stops generates a sink after
evaluating a constructor on a temporary object that has a no-return destructor.
This results in a loss of coverage because the time at which the destructor is
called may be after the time of construction (especially for lifetime-extended
temporaries).
This addresses PR15599.
rdar://problem/29131566
llvm-svn: 290140
Summary:
I originally added the -Wno-missing-braces flag because I thought it was
erroneously flagging std::array initializations. Now I realize the extra
braces really are desired for these initializations, so I'm turning the
warning flag back on.
Reviewers: jlebar
Subscribers: mgorny, parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D27941
llvm-svn: 290137
This handles all the corner cases if setting a section address:
- If the address is too low, we cannot allocate the program headers.
- If the load address is lowered, we have to do that before finalize
This also shares some code with the linker script since it was already
hitting similar cases.
This is used by the freebsd boot loader. It is not clear if we need to
support this with a non binary output, but it is not as bad as I was
expecting.
llvm-svn: 290136
`RawComments` are sorted by comparing underlying `SourceLocation`'s. This is
done by comparing `FileID` and `Offset`; when the `FileID` is the same it means
the locations are within the same TU and the `Offset` is used.
FileID, from the source code: "A mostly-opaque identifier, where 0 is
"invalid", >0 is this module, and <-1 is something loaded from another
module.". That said, when de-serializing SourceLocations, FileID's from
RawComments loaded from other modules get negative IDs where previously they
were positive. This makes imported RawComments unsorted, leading to a wrong
merge with other comments from the current TU. Fix that by sorting RawComments
properly after de-serialization and before merge.
This fixes an assertion in `ASTContext::getRawCommentForDeclNoCache`,
which fires only in a debug build of clang.
Differential Revision: https://reviews.llvm.org/D27546
rdar://problem/29287314
llvm-svn: 290134
Summary:
The expression for computing the return value of getMemOpBaseRegImmOfs has only
one possible value. The other value would result in a return earlier in the
function. This patch replaces the expression with its only possible value.
Reviewers: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27437
llvm-svn: 290133
This is especially important for arrays, since no one knows the proper
syntax for putting qualifiers in arrays.
nullability.h:3:26: warning: array parameter is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)
void arrayParameter(int x[]);
^
nullability.h:3:26: note: insert '_Nullable' if the array parameter may be null
void arrayParameter(int x[]);
^
_Nullable
nullability.h:3:26: note: insert '_Nonnull' if the array parameter should never be null
void arrayParameter(int x[]);
^
_Nonnull
rdar://problem/29524992
llvm-svn: 290132
DWARF 4 and later supports encoding the PC as an address or as as offset from the low PC. Clients using DWARFDie should be insulated from how to extract the high PC value. This function takes care of extracting the form value and looking for the correct form.
Differential Revision: https://reviews.llvm.org/D27885
llvm-svn: 290131
--retain-symbols-file=filename
Retain only the symbols listed in the file filename, discarding all others.
filename is simply a flat file, with one symbol name per line. This option
is especially useful in environments (such as VxWorks) where a large global
symbol table is accumulated gradually, to conserve run-time memory.
Note: though documentation says "--retain-symbols-file does not discard
undefined symbols, or symbols needed for relocations.", both bfd and gold
do that, and this patch too, like testcase show.
Differential revision: https://reviews.llvm.org/D27716
llvm-svn: 290122
In ASan, we have __asan_locate_address and __asan_get_alloc_stack, which is used in LLDB/Xcode to show the allocation backtrace for a heap memory object. This patch implements the same for TSan.
Differential Revision: https://reviews.llvm.org/D27656
llvm-svn: 290119
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored
to properly substitute primitive types using a hook in the itanium demangler,
and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement
primitive type parameter as before but parses it using the FastDemangler, which
has been modified to be able to notify clients of parse events (primitive types
at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so
that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223
Subscribers: lldb-commits
llvm-svn: 290117
mingw32-ld complains missing symbols in exports,
Cannot export clang_findIncludesInFileWithBlock: symbol not defined
Cannot export clang_findReferencesInFileWithBlock: symbol not defined
Cannot export clang_visitChildrenWithBlock: symbol not defined
They are excluded conditionally in header along has_blocks.
We should do either;
1. Exclude also function bodies conditionally, and introduce "optional" exporter.
2. Give dummy function bodies for them.
3. Implement functions w/o blocks.
llvm-svn: 290113
This allows lowering i8 and i16 arguments if they can fit in the registers. Note
that the lowering is incomplete - ABI extensions are handled in a subsequent
patch.
(Last part of)
Differential Revision: https://reviews.llvm.org/D27704
llvm-svn: 290106
Teach the instruction selector and legalizer that it's ok to have adds with 8 or
16-bit integers.
This is the second part of https://reviews.llvm.org/D27704
llvm-svn: 290105
Teach the instruction selector that it's ok to copy small values from physical
registers.
First part of https://reviews.llvm.org/D27704
llvm-svn: 290104
Chandler Carruth