Eli Friedman [Thu, 26 Jan 2012 03:00:14 +0000 (03:00 +0000)]
Refactor to share code for handling return statements between lambda expressions and block literals. As it turns out, almost all the logic can be shared.
-fixit-recompile
applies fixits and recompiles the result
-fixit-to-temporary
applies fixits to temporary files
-fix-only-warnings">,
applies fixits for warnings only, not errors
Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.
Rafael Espindola [Thu, 26 Jan 2012 02:02:57 +0000 (02:02 +0000)]
Fix our handling of #pragma GCC visibility.
Now the lexer just produces a token and the parser is the one responsible for
activating it.
This fixes problem like the one pr11797 where the lexer and the parser were not
in sync. This also let us be more strict on where in the file we accept
these pragmas.
Chandler Carruth [Thu, 26 Jan 2012 01:35:15 +0000 (01:35 +0000)]
Reintroduce r148981 with significantly improved regression test. Now it
both actually tests what it wants to, doesn't have bogus and broken
assertions in it, and is also formatted much more cleanly and
consistently. Probably still some more that can be improved here, but
its much better.
Original commit message:
----
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
Ted Kremenek [Wed, 25 Jan 2012 23:47:14 +0000 (23:47 +0000)]
Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed
to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which
shows up with inlining).
Revert r148981 because it fails test/Driver/freebsd.c
Original log:
Author: chandlerc <chandlerc@91177308-0d34-0410-b5e6-96231b3b80d8>
Date: Wed Jan 25 21:32:31 2012 +0000
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
Chandler Carruth [Wed, 25 Jan 2012 21:32:31 +0000 (21:32 +0000)]
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.
Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.
Chandler Carruth [Wed, 25 Jan 2012 21:03:58 +0000 (21:03 +0000)]
Restore a tiny bit of functionality that I completely overlooked in the
Linux toolchain selection -- sorry folks. =] This should fix the Hexagon
toolchain.
However, I would point out that I see why my testing didn't catch this
-- we have no tests for Hexagon. ;]
Kaelyn Uhrain [Wed, 25 Jan 2012 20:49:08 +0000 (20:49 +0000)]
Avoid correcting unknown identifiers to types where types aren't allowed.
Pass a typo correction callback object from ParseCastExpr to
Sema::ActOnIdExpression to be a bit more selective about what kinds of
corrections will be allowed for unknown identifiers.
Kaelyn Uhrain [Wed, 25 Jan 2012 18:37:44 +0000 (18:37 +0000)]
Add custom callback object for typo correction in BuildRecoveryCallExpr.
The new callback, in addition to limiting which keywords to include in
the pool of typo correction candidates, also filters out non-keyword
candidates that don't refer to (template) functions that accept the
number of arguments that are present for the call being recovered.
Douglas Gregor [Wed, 25 Jan 2012 16:15:54 +0000 (16:15 +0000)]
When we're substituting into a function parameter pack and expect to
get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.
Chandler Carruth [Wed, 25 Jan 2012 11:24:24 +0000 (11:24 +0000)]
The Linux pattern of adding all the search paths that exist doesn't seem
to suit the FreeBSD folks. Take them back to something closer to the old
behavior. We test whether the /usr/lib32 directory exists (within the
SysRoot), and use it if so, otherwise use /usr/lib.
FreeBSD folks, let me know if this causes any problems, or if you have
further tweaks.
Chandler Carruth [Wed, 25 Jan 2012 11:18:20 +0000 (11:18 +0000)]
Remove the 'ToolTriple' concept from the NetBSD toolchain along with my
gross hack to provide it from my previous patch removing HostInfo. This
was enshrining (and hiding from my searches) the concept of storing and
diff-ing the host and target triples. We don't have the host triple
reliably available, so we need to merely inspect the target system. I've
changed the logic in selecting library search paths for NetBSD to match
what I provided for FreeBSD -- we include both search paths, but put the
32-bit-on-64-bit-host path first so it trumps.
NetBSD maintainers, you may want to tweak this, or feel free to ask me
to tweak it. I've left a FIXME here about the challeng I see in fixing
this properly.
Chandler Carruth [Wed, 25 Jan 2012 11:01:57 +0000 (11:01 +0000)]
Delete the driver's HostInfo class. This abstraction just never really
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
- Neither of these have anything to do with the host, or its info.
- The HostInfo class was setup as a full blown class *hierarchy* with
a separate implementation for each "host" OS. This required
dispatching just to create the objects in the first place.
- The hierarchy claimed to represent the host, when in fact it was
based on the target OS.
- Each leaf in the hierarchy was responsible for implementing the flag
processing and caching, resulting in a *lot* of copy-paste code and
quite a few bugs.
- The caching was consistently done based on architecture alone, even
though *any* aspect of the targeted triple might change the behavior
of the configured toolchain.
- Flag processing was already being done in the Driver proper,
separating the flag handling even more than it already is.
Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.
The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.
This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!
Chandler Carruth [Wed, 25 Jan 2012 10:50:34 +0000 (10:50 +0000)]
Add some really minimalist freebsd testing trees and use them in the
freebsd test so that it's behavior isn't dependent on the filesystem of
the host running the tests. This should revive the build bots at least.
The tests and the trees still need a lot of love to make them as useful
and easy to maintain as linux-ld.c.
Chandler Carruth [Wed, 25 Jan 2012 09:12:06 +0000 (09:12 +0000)]
Switch the ToolChain types to all store a Driver reference rather than
a HostInfo reference. Nothing about the HostInfo was used by any
toolchain except digging out the driver from it. This just makes that
a lot more direct. The change was accomplished entirely mechanically.
It's one step closer to removing the shim full of buggy copy/paste code
that is HostInfo.
Chandler Carruth [Wed, 25 Jan 2012 08:49:21 +0000 (08:49 +0000)]
Remove the TargetTriple object that I added to the Driver recently. This
helped stage the refactoring of things a bit, but really isn't the right
place for it. The driver may be responsible for compilations with many
different targets. In those cases, having a target triple in the driver
is actively misleading because for many of those compilations that is
not actually the triple being targeted.
This moves the last remaining users of the Driver's target triple to
instead use the ToolChain's target triple. The toolchain has a single,
concrete target it operates over, making this a more stable and natural
home for it.
Chandler Carruth [Wed, 25 Jan 2012 08:10:33 +0000 (08:10 +0000)]
Have FreeBSD use even more of the same smarts as Linux is now using for
adding search paths. Add them only when they exist, and prefix the paths
with the sysroot. This will allow targeting a FreeBSD sysroot on
a non-FreeBSD host machine, and perhaps more importantly should allow
testing the FreeBSD driver's behavior similarly to the Linux tests with
a fake tree of files in the regression test suite.
I don't have FreeBSD systems handy to build up the list of files that
should be used here, but this is the basic functionality and I'm hoping
Roman or someone from the community can contribute the actual test
cases.
Chandler Carruth [Wed, 25 Jan 2012 08:04:15 +0000 (08:04 +0000)]
Switch FreeBSD to just include both '/usr/lib32' and '/usr/lib' in the
search paths for 32-bit targets. This avoids having to detect which is
expected for the target system, and the linker should DTRT, and take the
32-bit libraries from the first one when applicable. Thanks to Roman
Divacky for sanity checking this.
Chandler Carruth [Wed, 25 Jan 2012 07:21:38 +0000 (07:21 +0000)]
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
Chris Lattner [Wed, 25 Jan 2012 05:34:41 +0000 (05:34 +0000)]
reapply r148902:
"use the new ConstantVector::getSplat method where it makes sense."
Also simplify a bunch of code to use the Builder->getInt32 instead
of doing it the hard and ugly way. Much more progress could be made
here, but I don't plan to do it.
Richard Smith [Wed, 25 Jan 2012 02:14:59 +0000 (02:14 +0000)]
Fix PR11848: decree that an alias template contains an unexpanded parameter pack
iff its substitution contains an unexpanded parameter pack. This has the effect
that we now reject declarations such as this (which we used to crash when
expanding):
template<typename T> using Int = int;
template<typename ...Ts> void f(Int<Ts> ...ints);
The standard is inconsistent on how this case should be treated.
Nick Lewycky [Wed, 25 Jan 2012 01:19:14 +0000 (01:19 +0000)]
With a little more work in the tentative parse determining whether a statement
is a declaration-stmt or an expression, we can discern a subset of cases where
the user erred in omitting the typename keyword before a dependent type name.
Fixes PR11358!
Douglas Gregor [Wed, 25 Jan 2012 01:14:32 +0000 (01:14 +0000)]
Introduce a generation number for selector lookups in the global
method pool, so that we don't perform the same lookups into the same
PCH/module file repeatedly.
Douglas Gregor [Wed, 25 Jan 2012 00:59:09 +0000 (00:59 +0000)]
Whenever Sema attempts to look in the global method pool, try to load
additional data from the external Sema source. This properly copes
with modules that are imported after we have already searched in the
global method pool for a given selector. For PCH, it's a slight
pessimization to be fixed soon.
Douglas Gregor [Wed, 25 Jan 2012 00:49:42 +0000 (00:49 +0000)]
Rework the external Sema source's ReadMethodPool() so that it doesn't
return pre-built lists. Instead, it feeds the methods it deserializes
to Sema so that Sema can unique them, which keeps the chains shorter.
Ted Kremenek [Wed, 25 Jan 2012 00:35:05 +0000 (00:35 +0000)]
Reduce peak memory usage of the static analyzer on sqlite3 (when using inlining) by 30%.
This is accomplished by periodically reclaiming nodes in the graph. This was an optimization
done before the CFG was linearized, but the CFG linearization destroyed that optimization since each
freshly created node couldn't be reclaimed and we only looked at a window of nodes created between
each ProcessStmt. This optimization can be reclaimed my merely expanding the window to N number of nodes.
arc migrator: Provide infrastructure to add options
specific to migrator. Use its first option to
warn migrating from GC to arc when
NSAllocateCollectable/NSReallocateCollectable is used.
// rdar://10532541
Douglas Gregor [Wed, 25 Jan 2012 00:19:56 +0000 (00:19 +0000)]
Factor out the addition of a method into the global method pool, and
teach it to always add the new method at the *end* of the list rather
than as the second element in the list.
[libclang] In clang::getCursorKindForDecl() don't return "UnexposedDecl"
for forward references of classes and protocols, this breaks libclang API usage.
Nick Lewycky [Tue, 24 Jan 2012 21:15:41 +0000 (21:15 +0000)]
Add a new warning, -Wover-aligned, which detects attempts to use the default
allocator to construct an object which declares more alignment than the default
allocator actually provides. Fixes PR9527!
Chandler Carruth [Tue, 24 Jan 2012 20:08:17 +0000 (20:08 +0000)]
Fix one of the (larger) FIXMEs where we were misusing the Driver's idea
of the target triple to stand in for the "host" triple.
Thanks to a great conversation with Richard Smith, I'm now much more
confident in how this is proceeding. In all of the places where we
currently reason about the "host" architecture or triple, what we really
want to reason about in the detected GCC installation architecture or
triple, and the ways in which that differs from the target. When we find
a GCC installation with a different triple from our target *but capable
of targeting our target* through an option such as '-m64', we want to
detect *that* case and change the paths within the GCC installation (and
libstdc++ installation) to reflect this difference.
This patch makes one function do this correctly. Subsequent commits will
hoist the logic used here into the GCCInstallation utility, and then
reuse it through the rest of the toolchains to fix the remaining places
where this is currently happening.
[libclang] When calling clang_getCursorReferenced on a class or protocol
forward reference, do give an interface or protocol cursor back, don't give
an 'UnexposedDecl' one.
Chandler Carruth [Tue, 24 Jan 2012 19:28:29 +0000 (19:28 +0000)]
Address one part of the FIXME I introduced my switching the triple
inside of GCCInstallation to be a proper llvm::Triple. This is still
a touch ugly because we have to use it as a string in so many places,
but I think on the whole the more structured representation is better.
Comments of course welcome if this tradeoff isn't working for folks.
The following patch adds __attribute__((no_address_safety_analysis)) which will allow to disable
address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.
When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).
With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.
Chandler Carruth [Tue, 24 Jan 2012 19:17:46 +0000 (19:17 +0000)]
Start hoisting the logic for computing the target triple into its own
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
Douglas Gregor [Tue, 24 Jan 2012 19:01:26 +0000 (19:01 +0000)]
Promote the extension warning for attempts to catch a reference or
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.
Douglas Gregor [Tue, 24 Jan 2012 15:24:38 +0000 (15:24 +0000)]
Only mark an IdentifierInfo as having changed since deserialization
when it actually has changed (and not, e.g., when we've simply attached a
deserialized macro definition). Good for ~1.5% reduction in module
file size, mostly in the identifier table.
projects / clang / log