Kristof Umann [Sat, 26 Jan 2019 21:41:50 +0000 (21:41 +0000)]
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.
Kristof Umann [Sat, 26 Jan 2019 20:06:54 +0000 (20:06 +0000)]
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Kristof Umann [Sat, 26 Jan 2019 17:27:40 +0000 (17:27 +0000)]
[analyzer] Fix an bug where statically linked, but not registered checkers weren't recognized
My last patch, D56989, moved the validation of whether a checker exists into
its constructor, but we do support statically linked (and non-plugin) checkers
that were do not have an entry in Checkers.td. However, the handling of this
happens after the creation of the CheckerRegistry object.
This patch fixes this bug by moving even this functionality into
CheckerRegistry's constructor.
Kristof Umann [Sat, 26 Jan 2019 16:35:33 +0000 (16:35 +0000)]
[analyzer][NFC] Keep track of whether enabling a checker was explictly specified in command line arguments
I added a new enum to CheckerInfo, so we can easily track whether the check is
explicitly enabled, explicitly disabled, or isn't specified in this regard.
Checkers belonging in the latter category may be implicitly enabled through
dependencies in the followup patch. I also made sure that this is done within
CheckerRegisty's constructor, leading to very significant simplifications in
its query-like methods.
Kristof Umann [Sat, 26 Jan 2019 15:56:40 +0000 (15:56 +0000)]
[analyzer] Split unix.API up to UnixAPIMisuseChecker and UnixAPIPortabilityChecker
The actual implementation of unix.API features a dual-checker: two checkers in
one, even though they don't even interact at all. Split them up, as this is a
problem for establishing dependencies.
I added no new code at all, just merely moved it around.
Since the plist files change (and that's a benefit!) this patch isn't NFC.
Kristof Umann [Sat, 26 Jan 2019 14:23:08 +0000 (14:23 +0000)]
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. This will force every
checker to implement this function, but maybe it isn't that bad: I saw a lot of
ObjC or C++ specific checkers that should probably not register themselves based
on some LangOptions (mine too), but they do anyways.
A big benefit of this is that all registry functions now register their checker,
once it is called, registration is guaranteed.
This patch is a part of a greater effort to reinvent checker registration, more
info here: D54438#1315953
Bruno Ricci [Sat, 26 Jan 2019 14:15:10 +0000 (14:15 +0000)]
[AST] Pack GenericSelectionExpr
Store the controlling expression, the association expressions and the
corresponding TypeSourceInfos as trailing objects.
Additionally use the bit-fields of Stmt to store one SourceLocation,
saving one additional pointer. This saves 3 pointers in total per
GenericSelectionExpr.
Bruno Ricci [Sat, 26 Jan 2019 13:58:15 +0000 (13:58 +0000)]
[AST][NFC] Various cleanups to GenericSelectionExpr
Various cleanups to GenericSelectionExpr factored out of D57104. In particular:
1. Move the friend declaration to the top.
2. Introduce a constant ResultDependentIndex instead of the magic "-1".
3. clang-format
4. Group the member function together so that they can be removed as one block
by D57106.
Craig Topper [Sat, 26 Jan 2019 02:42:01 +0000 (02:42 +0000)]
[X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.
Summary:
The 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics all have the possibility of taking an explicit rounding mode argument. If the rounding mode is CUR_DIRECTION we'd like to emit a sitofp/uitofp instruction and a select like we do for 256-bit intrinsics.
For cvt(u)qqtopd and cvt(u)dqtops we do this when the form of the software intrinsics that doesn't take a rounding mode argument is used. This is done by using convertvector in the header with the select builtin. But if the explicit rounding mode form of the intrinsic is used and CUR_DIRECTION is passed, we don't do this. We shouldn't have this inconsistency.
For cvt(u)qqtops nothing is done because we can't use the select builtin in the header without avx512vl. So we need to use custom codegen for this.
Even when the rounding mode isn't CUR_DIRECTION we should also use select in IR for consistency. And it will remove another scalar integer mask from our intrinsics.
To accomplish all of these goals I've taken a slightly unusual approach. I've added two new X86 specific intrinsics for sitofp/uitofp with rounding. These intrinsics are variadic on the input and output type so we only need 2 instead of 6. This avoids the need for a switch to map them in CGBuiltin.cpp. We just need to check signed vs unsigned. I believe other targets also use variadic intrinsics like this.
So if the rounding mode is CUR_DIRECTION we'll use an sitofp/uitofp instruction. Otherwise we'll use one of the new intrinsics. After that we'll emit a select instruction if needed.
Nico Weber [Fri, 25 Jan 2019 23:37:57 +0000 (23:37 +0000)]
Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF
libclang can be built in shared or static mode. On Windows, with
LLVM_ENABLE_PIC=OFF, it was built in neither mode, leading to clients of
libclang (c-index-test, c-arcmt-test) failing to link with it set.
Since PIC isn't really a thing on Windows, build libclang in shared mode when
LLVM_ENABLE_PIC=OFF there. This is also somewhat symmetric with the existing
ENABLE_STATIC a few lines down.
Stella Stamenova [Fri, 25 Jan 2019 23:03:12 +0000 (23:03 +0000)]
Fixed frontend clang tests in windows read-only container
Summary:
When mounting LLVM source into a windows container in read-only mode, certain tests fail. Ideally, we want all these tests to pass so that developers can mount the same source folder into multiple (windows) containers simultaneously, allowing them to build/test the same source code using various different configurations simultaneously.
**Fix**: I've found that when attempting to open a file for writing on windows, if you don't have the correct permissions (trying to open a file for writing in a read-only folder), you get [Access is denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f). In llvm, we map this error message to a linux based error, see: https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp
This is why we see "Permission denied" in our output as opposed to the expected "No such file or directory", thus causing the tests to fail.
I've changed the test locally to instead point to the root drive so that they can successfully bypass the Access is denied error when LLVM is mounted in as a read-only directory. This way, the test operate exactly the same, but we can get around the windows-complications of what error to expect in a read-only directory.
Reid Kleckner [Fri, 25 Jan 2019 19:18:40 +0000 (19:18 +0000)]
[CodeGen] Implement isTriviallyRecursive with StmtVisitor instead of RecursiveASTVisitor
This code doesn't need to traverse types, lambdas, template arguments,
etc to detect trivial recursion. We can do a basic statement traversal
instead. This reduces the time spent compiling CodeGenModule.cpp, the
object file size (mostly reduced debug info), and the final executable
size by a small amount. I measured the exe mostly to check how much of
the overhead is from debug info, object file section headers, etc, vs
actual code.
metric | before | after | diff
time (s) | 47.4 | 38.5 | -8.9
obj (kb) | 12888 | 12012 | -876
exe (kb) | 86072 | 85996 | -76
Erich Keane [Fri, 25 Jan 2019 18:36:20 +0000 (18:36 +0000)]
Remove F16 literal support based on Float16 support.
Float16 support was disabled recently on many platforms, however that
commit still allowed literals of Float16 type to work. This commit
removes those based on the same logic as Float16 disable.
Erich Keane [Fri, 25 Jan 2019 17:27:57 +0000 (17:27 +0000)]
Disable _Float16 for non ARM/SPIR Targets
As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html
There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.
Erich Keane [Fri, 25 Jan 2019 17:01:42 +0000 (17:01 +0000)]
Allow 'static' storage specifier on an out-of-line member function template
declaration in MSVCCompat mode
Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.
This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).
Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.
Petr Hosek [Fri, 25 Jan 2019 02:42:30 +0000 (02:42 +0000)]
[AArch64] Make the test for rsr and rsr64 stricter
ACLE specifies that return type for rsr and rsr64 is uint32_t and
uint64_t respectively. D56852 change the return type of rsr64 from
unsigned long to unsigned long long which at least on Linux doesn't
match uint64_t, but the test isn't strict enough to detect that
because compiler implicitly converts unsigned long long to uint64_t,
but it breaks other uses such as printf with PRIx64 type specifier.
This change makes the test stricter enforcing that the return type
of rsr and rsr64 builtins is what is actually specified in ACLE.
Petr Hosek [Fri, 25 Jan 2019 02:16:29 +0000 (02:16 +0000)]
Revert "[AArch64] Use LL for 64-bit intrinsic arguments"
This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.
George Karpenkov [Fri, 25 Jan 2019 01:23:51 +0000 (01:23 +0000)]
[analysis] Introduce an AnyCall helper class, for abstraction over different callables
A lot of code, particularly in the analyzer, has to perform a lot of
duplication to handle functions/ObjCMessages/destructors/constructors in
a generic setting.
The analyzer already has a CallEvent helper class abstracting over such
calls, but it's not always suitable, since it's tightly coupled to other
analyzer classes (ExplodedNode, ProgramState, etc.) and it's not always
possible to construct.
This change introduces a very simple, very lightweight helper class to
do simple generic operations over callables.
In future, parts of CallEvent could be changed to use this class to
avoid some duplication.
George Karpenkov [Fri, 25 Jan 2019 01:23:37 +0000 (01:23 +0000)]
[AST] Add a method to get a call type from an ObjCMessageExpr
Due to references, expression type does not always correspond to an
expected method return type (e.g. for a method returning int & the
expression type of the call would still be int).
We have a helper method for getting the expected type on CallExpr, but
not on ObjCMessageExpr.
Alex Lorenz [Thu, 24 Jan 2019 23:07:58 +0000 (23:07 +0000)]
[clang-format] square parens with one token are not Objective-C message sends
The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.
Alex Lorenz [Thu, 24 Jan 2019 19:14:39 +0000 (19:14 +0000)]
Add a priority field to availability attributes to prioritize explicit
attributes from declaration over attributes from '#pragma clang attribute'
Before this commit users had an issue when using #pragma clang attribute with
availability attributes:
The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.
This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:
- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
are discarded if there's an explicit attribute or an attribute specified
using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
#pragma are not used if there's an explicit, explicit #pragma, or an
implicit attribute inferred from an explicit attribute for the declaration.
This is the resulting ranking:
`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`
Sam McCall [Thu, 24 Jan 2019 18:55:24 +0000 (18:55 +0000)]
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Erich Keane [Thu, 24 Jan 2019 15:28:57 +0000 (15:28 +0000)]
[CPU-Dispatch] Make pentium_iii_no_xmm_regs and pentium_iii alias.
I discovered that in ICC (where this list comes from), that the two
pentium_iii versions were actually identical despite the two different
names (despite them implying a difference). Because of this, they ended
up having identical manglings, which obviously caused problems when used
together.
This patch makes pentium_iii_no_xmm_regs an alias for pentium_iii so
that it can still be used, but has the same meaning as ICC. However, we
still prohibit using the two together which is different (albeit better)
behavior.
Gabor Marton [Thu, 24 Jan 2019 14:47:44 +0000 (14:47 +0000)]
[ASTImporter] Fix inequality of functions with different attributes
Summary:
FunctionType::ExtInfo holds such properties of a function which are needed
mostly for code gen. We should not compare these bits when checking for
structural equivalency.
Checking ExtInfo caused false ODR errors during CTU analysis (of tmux).
Serge Guelton [Thu, 24 Jan 2019 10:34:44 +0000 (10:34 +0000)]
Fix python3 compability issue in clang binding
The file contents could be of str type. Should use byte length instead
of str length, otherwise utf-8 encoded files may not get properly parsed
for completion.
Hsiangkai Wang [Thu, 24 Jan 2019 05:34:29 +0000 (05:34 +0000)]
Reland r345009 "[DebugInfo] Generate debug information for labels."
Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.
After fixing PR37395.
After fixing problems in LiveDebugVariables.
After fixing NULL symbol problems in AddressPool when enabling
split-dwarf-file.
After fixing PR39094.
After landing D54199 and D54465 to fix Chromium build failed.
Julian Lettner [Thu, 24 Jan 2019 01:06:19 +0000 (01:06 +0000)]
[Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls
Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every `unreachable` instruction. However,
the optimizer will remove code after calls to functions marked with
`noreturn`. To avoid this UBSan removes `noreturn` from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
`_asan_handle_no_return` before `noreturn` functions. This is important
for functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* `longjmp` (`longjmp` itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the `noreturn` attributes are missing and ASan
cannot unpoison the stack, so it has false positives when stack
unwinding is used.
Changes:
# UBSan now adds the `expect_noreturn` attribute whenever it removes
the `noreturn` attribute from a function
# ASan additionally checks for the presence of this attribute
Leonard Chan [Thu, 24 Jan 2019 00:11:35 +0000 (00:11 +0000)]
[Sema] Fix Modified Type in address_space AttributedType
This is a fix for https://reviews.llvm.org/D51229 where we pass the
address_space qualified type as the modified type of an AttributedType. This
change now instead wraps the AttributedType with either the address_space
qualifier or a DependentAddressSpaceType.
Raphael Isemann [Tue, 22 Jan 2019 17:59:45 +0000 (17:59 +0000)]
[ASTImporter] Fix importing OperatorDelete from CXXConstructorDecl
Summary:
Shafik found out that importing a CXXConstructorDecl will create a translation unit that
causes Clang's CodeGen to crash. The reason for that is that we don't copy the OperatorDelete
from the CXXConstructorDecl when importing. This patch fixes it and adds a test case for that.
Eli Friedman [Tue, 22 Jan 2019 00:11:17 +0000 (00:11 +0000)]
[CodeGen] Always use string computed in Sema for PredefinedExpr
We can't use any other string, anyway, because its type wouldn't
match the type of the PredefinedExpr.
With this change, we don't compute a "nice" name for the __func__ global
when it's used in the initializer for a constant. This doesn't seem like
a great loss, and I'm not sure how to fix it without either storing more
information in the AST, or somehow threading through the information
from ExprConstant.cpp.
This could break some situations involving BlockDecl; currently,
CodeGenFunction::EmitPredefinedLValue has some logic to intentionally
emit a string different from what Sema computed. This code skips that
logic... but that logic can't work correctly in general anyway. (For
example, sizeof(__func__) returns the wrong result.) Hopefully this
doesn't affect practical code.
Michal Gorny [Mon, 21 Jan 2019 17:05:43 +0000 (17:05 +0000)]
[test] Pass -ccc-install-dir in mac compilation db test
Pass -ccc-install-dir explicitly as the compilation database code does
not pass argv[0] to getMainExecutable(), while some systems require it
to return the correct path. Since the relevant code is apparently only
applicable to Darwin, just pass correct -ccc-install-dir to make
the tests pass on *BSD systems.
[OpenCL] Allow address spaces as method qualifiers.
Methods can now be qualified with address spaces to prevent
undesirable conversions to generic or to provide custom
implementation to be used if the object is located in certain
memory segments.
This commit extends parsing and standard C++ overloading to
work for an address space of a method (i.e. implicit 'this'
parameter).
Jonas Toth [Mon, 21 Jan 2019 13:26:18 +0000 (13:26 +0000)]
[clang] add tests to ExprMutAnalyzer that reproduced a crash in ASTMatchers
Summary:
This patch adds two unit-tests that are the result of reducing a crashing TU
when running ExprMutAnalyzer over it. They are added only to ensure the regression
that has been fixed with https://reviews.llvm.org/D56444 don't creep back.
Sam Parker [Mon, 21 Jan 2019 11:01:05 +0000 (11:01 +0000)]
[AArch64] Use LL for 64-bit intrinsic arguments
The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are
uint64_t so we should have the clang builtin match this description
- which is what we already do for AArch32.
Chandler Carruth [Mon, 21 Jan 2019 09:52:34 +0000 (09:52 +0000)]
Fix typos throughout the license files that somehow I and my reviewers
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
Serge Guelton [Sun, 20 Jan 2019 21:19:56 +0000 (21:19 +0000)]
Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Chandler Carruth [Sat, 19 Jan 2019 08:50:56 +0000 (08:50 +0000)]
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
Chandler Carruth [Sat, 19 Jan 2019 06:36:08 +0000 (06:36 +0000)]
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
Chandler Carruth [Sat, 19 Jan 2019 06:29:07 +0000 (06:29 +0000)]
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.
Chandler Carruth [Sat, 19 Jan 2019 06:14:24 +0000 (06:14 +0000)]
Install new LLVM license structure and new developer policy.
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Emit !callback metadata and introduce the callback attribute
With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive calls.
The general idea is that we use an abstraction to hide the middle man
and represent the callback call in the context of the initial caller.
It is described in more detail in the commit message of the LLVM patch
r351627, the llvm::AbstractCallSite class description, and the
language reference section on callback-metadata.
This commit enables clang to emit !callback metadata that is
understood by LLVM. It does so in three different cases:
1) For known broker functions declarations that are directly
generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
2) For known broker functions that are identified by their name and
source location through the builtin detection, e.g.,
pthread_create from the POSIX thread API.
3) For user annotated functions that carry the "callback(callee, ...)"
attribute. The attribute has to include the name, or index, of
the callback callee and how the passed arguments can be
identified (as many as the callback callee has). See the callback
attribute documentation for detailed information.
Artem Dergachev [Fri, 18 Jan 2019 23:05:07 +0000 (23:05 +0000)]
[analyzer] pr37688: Fix a crash upon evaluating a deleted destructor of a union.
Add a defensive check against an invalid destructor in the CFG.
Unions with fields with destructors have their own destructor implicitly
deleted. Due to a bug in the CFG we're still trying to evaluate them
at the end of the object's lifetime and crash because we are unable
to find the destructor's declaration.
Artem Dergachev [Fri, 18 Jan 2019 22:52:13 +0000 (22:52 +0000)]
[analyzer] Do not try to body-farm Objective-C properties with custom accessors.
If a property is defined with a custom getter, we should not behave as if
the getter simply returns an instance variable. We don't support setters,
so they aren't affected.
On top of being the right thing to do, this also fixes a crash on
the newly added test - in which a property and its getter are defined
in two separate categories.
projects / clang / log