objc++: For atomic properties of c++ class objec typet, appropriate
operator= is called. Issue a warning for non-trivial case until
runtime support is provided. // rdar://6137845
Richard Smith [Thu, 6 Oct 2011 09:21:12 +0000 (09:21 +0000)]
PR11067: A definition of a constexpr static variable doesn't need an initializer if the in-class declaration had one. Such a declaration must be initialized by a constant expression.
[libclang] Introduce clang_findReferencesInFile which accepts a cursor, a file,
and a callback and finds all identifier references of the cursor in the file.
[libclang] Move the bulk of clang_getOverriddenCursors into
a cxcursor::getOverriddenCursors C++ function, because SmallVectors
are groovier that malloc'ing buffers.
When constructing debug information for synthesized variables for the
non-fragile ABI we may not be able to lay out the type and the debugger
would ignore us even if we did put in the offset. Go ahead and just
put any value there and don't look up the offset since it may not exist.
Anna Zaks [Wed, 5 Oct 2011 23:37:30 +0000 (23:37 +0000)]
[analyzer] OSAtomicChecker implements evalCall in a very invasive way - it essentially simulates inlining of compareAndSwap() by means of setting the NodeBuilder flags and calling ExprEngine directly.
This commit introduces a new callback just for this checker to unblock checker API cleanup.
Chad Rosier [Wed, 5 Oct 2011 19:51:41 +0000 (19:51 +0000)]
[driver] The -v option doesn't quoted the command line arguments for historical
reasons. However, it does seems practical to quote strings that need it.
rdar://10221951
Douglas Gregor [Wed, 5 Oct 2011 14:53:30 +0000 (14:53 +0000)]
Introduce a simple file-based locking protocol for on-demand module
creation, so that only a single Clang instance will rebuild a given
module at once (and the others will wait).
We still don't clean up the lock files when we crash, which is a
rather unfortunate problem. I'll handle that next, and there is
certainly a *lot* of room for further improvements.
John McCall [Wed, 5 Oct 2011 07:41:44 +0000 (07:41 +0000)]
Refactor the analysis of C++ cast expressions so that even
C-style and functional casts are built in SemaCXXCast.cpp.
Introduce a helper class to encapsulate most of the random
state being passed around, at least one level down.
Teach Clang to cope with GCC installations that have unusual patch
"versions". Currently, these are just dropped on the floor, A concrete
version number will always win out.
Implement the feature I was originally driving toward when I started
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.
Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.
c: assignment/init of a function pointer whose function(s)
return to one which does not return (has noreturn attribute)
should warn as it is an unsafe assignment. // rdar://10095762
c++ already handles this. This is the c version.
Douglas Gregor [Tue, 4 Oct 2011 23:59:32 +0000 (23:59 +0000)]
Don't allow an rvalue reference to bind to the result of a calling a
conversion function whose result type is an lvalue reference. The
initialization code already handled this properly, but overload
resolution was allowing the binding. Fixes PR11003 /
<rdar://problem/10233078>.
Chad Rosier [Tue, 4 Oct 2011 22:35:48 +0000 (22:35 +0000)]
[driver] Improve r141053 by only emitting the warning if the original input
was assembly. Otherwise, something like -save-temps causes the integrated
assembler to warn.
Fix Windows+MinGW which introduces noise into path separators.
There should be a better solution to this; Michael and I are continuing
to discuss exactly what it should be. The one solution I'm very
uncomfortable with is making the FileCheck tests use a regex for each
path separator.
Now that multiple prefixes are much cheaper to search for GCC
installations, support them when installed directly under the system
root ('/lib/gcc/...' essentially).
With this, Clang can correctly detect and use a cross-compiling GCC
installation within a system root and use it.
Again, test cases will be coming in later commits, as I'm going to write
a few test cases that exercise nearly all of this logic.
Rework the search for a GCC installation still further. This combines
two fundamental changes, as they ended up being interrelated.
The first is to walk from the root down through the filesystem so that
we prune subtrees which do not exist early. This greatly reduces the
filesystem traffic of this routine. We store the "best" GCC version we
encounter, and look at all of the GCC installations available.
Also, we look through GCC versions by scanning the directory rather than
using a hard-coded list of versions. This has several benefits. It makes
it much more efficient to locate a GCC installation even in the presence
of a large number of different options by simply reading the directory
once. It also future-proofs us as new GCC versions are released and
installed. We no longer have a hard coded list of version numbers, and
won't need to manually updated it. We can still filter out known-bad
versions as needed. Currently I've left in filtering for all GCC
installations prior to 4.1.1, as that was the first one supported
previously.
Daniel Dunbar [Tue, 4 Oct 2011 21:17:24 +0000 (21:17 +0000)]
Basic/Diagnostics: Apparently, #pragma ... diagnostic is intended to override
the command line options (at least according to GCC's documentation). GCC 4.2
didn't appear to actually do this, but it seems like that has been fixed in
later release, so we will follow the docs.
Eli Friedman [Tue, 4 Oct 2011 20:31:48 +0000 (20:31 +0000)]
Remove a nonsensical bit of code from InitListChecker::getStructuredSubobjectInit which was increasing the reserved size for an init list past its maximum possible size. Fixes PR11056, a case where we were reserving a bunch of memory for arrays that was never actually used.
(No testcase because I don't think we have any way to actually write a testcase for this; the chosen value of NumElements has no effects on anything other than performance and memory usage.)
Add a comment explaining that I have a better plan for implementing the
GCC installation search that requires fewer filesystem operations.
Planning to implement that next as the current approcah while thorough
(and so far looks correct) does a very unfortunate number of filesystem
operations.
I'm motivated to fix this in no small part because I would like to
support a much larger space of triples and GCC versions, which would
explode the current algorithm.
Invert the loop for detecting installed GCC trees. This make the loop
find the newest GCC available, among other goodness. It makes the entire
system much less prone to error from prefixes and/or system roots
pruning early the set of triples and GCC versions available.
Also, improve some comments and simplify the forms of some of the loops.
This causes the driver to stat directories more often than is strictly
necessary, but the alternatives which I looked at that still
accomplished this goal needed quite a bit more code and were likely not
much faster.
Test cases for this, now that our behavior here is significantly more
principled and predictable, should come tomorrow as I walk back through
VMs looking for edge cases that are missed after this.
Fuse the two halves of the GCC installation detection. This is
significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.
Specifically, the logic now looks exhaustively for patterns such as:
/usr/lib/<triple>/gcc/<triple>
Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.
There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.
There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.
-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
class name, not the location of '@'.
Factor the data apart from the logic of locating various GCC
installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.
This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.
This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.
Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.
Chad Rosier [Tue, 4 Oct 2011 01:53:36 +0000 (01:53 +0000)]
[driver] Improve r141053 by only emitting the warning if the original input
was assembly. Otherwise, something like -save-temps causes the integrated
assembler to warn.
Douglas Gregor [Tue, 4 Oct 2011 00:21:21 +0000 (00:21 +0000)]
When build a module on demand, run the module-building job on a
separate thread with the "suitably large" stack, so we don't blow the
stack when building modules recursively.
Anna Zaks [Mon, 3 Oct 2011 21:55:56 +0000 (21:55 +0000)]
[analyzer] In UndefBranchChecker, use a node generator which does not create an edge/branching. (ExprEngine should be in charge of generating edges. The checkers should examine the condition and generate PostCondition node if needed.)
Anna Zaks [Mon, 3 Oct 2011 21:16:32 +0000 (21:16 +0000)]
[analyzer] Cleanup in UndefBranchChecker:
- Remove unused FindUndefExpr::ProgramStateManager.
- The Condition parameter of the callback is the terminator of the block, no need to retrieve it again.
Refactor the detection of a GCC installation into a helper class. This
is designed to allow the detection to record more rich information about
the installation than just a single path.
Mostly, the functionality remains the same. This is primarily
a factoring change. However, the new factoring immediately fixes one
issue where on ubuntu we didn't walk up enough layers to reach the
parent lib path. I'll have a test tree for that once I finish making the
Ubuntu tree work reasonably.
Test a multilib setup on a 64-bit host. This is the far more common
configuration, although the test still stubs out more directories than
are necessary or common in order to exercise all of the lookup paths
observed with upstream GCC.
This finishes testing the distribution-independent and
GCC-installation-independent parts of the library path search logic.
More testing is still needed for the triple detection, GCC-installation
detection, and handling distributions with unusual configurations.
Enable generic multilib support on 32bit hosts. Previously this was only
enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.
With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.
Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.
If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.
Relax an assertion here a bit. This doesn't really matter, as we won't
include *any* path on crtbegin.o unless we actually find such a file via
one of the search paths. We still strictly check the search paths right
after this, so we'll catch any issues there.
The reason for this is that the driver does some normalization of the
path on the actual object file, and this changes the textual format of
the string on Windows. It no longer matches the textual format of the
sysroot flag.
Test that we include a GCC-triple-prefixed tree. While I don't know of
any distros that use this, building a multilib GCC from mainline will
install linker scripts here.
Teach the logic for locating an installed GCC about the system root.
This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.
Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.
projects / clang / log