and through to the debug info in the module. In order to make the
testcase a bit more efficient allow the filename to go through
compilation for compile and not assemble jobs and turn off the
extract for cases where we don't create an object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175935 91177308-0d34-0410-b5e6-96231b3b80d8
Add an ability to specify custom documentation block comment commands via a new
class CommentOptions. The intention is that this class will hold future
customizations for comment parsing, including defining documentation comments
with specific numbers of parameters, etc.
CommentOptions instance is a member of LangOptions.
CommentOptions is controlled by a new command-line parameter
-fcomment-block-commands=Foo,Bar,Baz.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175892 91177308-0d34-0410-b5e6-96231b3b80d8
to control the check for the C 5.2.4.1 / C++ [implimits] restriction on nesting
levels for parentheses, brackets and braces.
Some code with heavy macro use exceeds the default limit of 256, but we don't
want to increase it generally to avoid stack overflow on stack-constrained
systems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175855 91177308-0d34-0410-b5e6-96231b3b80d8
We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".
Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).
rdar://13079314
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175480 91177308-0d34-0410-b5e6-96231b3b80d8
The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174560 91177308-0d34-0410-b5e6-96231b3b80d8
since only one of them is allowed in command-line, process them separately.
Otherwise, if more than one is specified in the command-line, one is processed normally
and the others are going to be treated and included as header files.
Related to radar://13140508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174385 91177308-0d34-0410-b5e6-96231b3b80d8
Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.
This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and
constructors/destructors.
With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
People use the C preprocessor for things other than C files. Some of them
have Unicode characters. We shouldn't warn about Unicode characters
appearing outside of identifiers in this case.
There's not currently a way for the preprocessor to tell if it's in -E mode,
so I added a new flag, derived from the PreprocessorOutputOptions. This is
only used by the Unicode warnings for now, but could conceivably be used by
other warnings or even behavioral differences later.
<rdar://problem/13107323>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173881 91177308-0d34-0410-b5e6-96231b3b80d8
- The only group where it makes sense for the "ExternC" bit is System, so this
simplifies having to have the extra isCXXAware (or ImplicitExternC, depending
on what code you talk to) bit caried around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173859 91177308-0d34-0410-b5e6-96231b3b80d8
- This slightly decouples the path handling, since before the group sometimes
dominated the "use sysroot" bit, but it was still passed in via the API.
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173855 91177308-0d34-0410-b5e6-96231b3b80d8
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173848 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-modules-global-index -cc1 option to allow one to disable the
index for performance testing purposes, but with a 10% win in
-fsyntax-only time, there is no reason a user would do this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173707 91177308-0d34-0410-b5e6-96231b3b80d8
"-fmodules-global-index" and expand its behavior to include both the
use and generation of the global module index.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173404 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
The global module index is a "global" index for all of the module
files within a particular subdirectory in the module cache, which
keeps track of all of the "interesting" identifiers and selectors
known in each of the module files. One can perform a fast lookup in
the index to determine which module files will have more information
about entities with a particular name/selector. This information can
help eliminate redundant lookups into module files (a serious
performance problem) and help with creating auto-import/auto-include
Fix-Its.
The global module index is created or updated at the end of a
translation unit that has triggered a (re)build of a module by
scraping all of the .pcm files out of the module cache subdirectory,
so it catches everything. As with module rebuilds, we use the file
system's atomicity to synchronize.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173301 91177308-0d34-0410-b5e6-96231b3b80d8
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173254 91177308-0d34-0410-b5e6-96231b3b80d8
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172945 91177308-0d34-0410-b5e6-96231b3b80d8
option. MS-style inline asm can now be enabled by either -fasm-blocks or
-fms-extensions.
rdar://12808010
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169445 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168063 91177308-0d34-0410-b5e6-96231b3b80d8
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168027 91177308-0d34-0410-b5e6-96231b3b80d8
working with preprocessed testcases. This causes source locations in
diagnostics to point at the spelling location instead of the presumed location,
while still keeping the semantic effects of the line directives (entering and
leaving system-header mode, primarily).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168004 91177308-0d34-0410-b5e6-96231b3b80d8
generate expanded signature encoding to include types as we
already do this for protocol method lists.
// rdar://12109031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167997 91177308-0d34-0410-b5e6-96231b3b80d8
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167413 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.
Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167411 91177308-0d34-0410-b5e6-96231b3b80d8
header-search options into the module hash. We're just using
ADT/Hashing.hpp for this, which isn't as cryptographically strong as
I'd like, but it'll do. If someone contributes (say) and MD4
implementation, we'd happily switch to that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167397 91177308-0d34-0410-b5e6-96231b3b80d8
After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.
The next commit relies on this behavior to actually test anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166508 91177308-0d34-0410-b5e6-96231b3b80d8
implicitly-included PTH files during initialization, delaying the
mapping down to the "original source file" until after later in the
initialization process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166452 91177308-0d34-0410-b5e6-96231b3b80d8
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166444 91177308-0d34-0410-b5e6-96231b3b80d8
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166236 91177308-0d34-0410-b5e6-96231b3b80d8
passing -fretain-comments-from-system-headers. By default, the
compiler no longer parses such documentation comments, as they
can result in a noticeable compile time/PCH slowdown.
Fixes <rdar://problem/11860820>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163778 91177308-0d34-0410-b5e6-96231b3b80d8
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).
Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
(in particular, we probably need to be very careful with regard to
lifetime-extension when a temporary is bound to a reference,
C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
destructor in the CFG -- not even invalidate the object region.
To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163264 91177308-0d34-0410-b5e6-96231b3b80d8
There are two tests regressions that come from the fact that the Retain
Count checker does not cancel out inlining of ObjC methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162950 91177308-0d34-0410-b5e6-96231b3b80d8
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configuration data from the command line.
No clients yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162827 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen option to a LangOpt option. In turn, hoist the guard into the parser
so that we avoid the new (and fairly unstable) Sema/AST/CodeGen logic. This
should restore the behavior of clang to that prior to r158325.
<rdar://problem/12163681>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162602 91177308-0d34-0410-b5e6-96231b3b80d8
Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.
C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)
The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162318 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162252 91177308-0d34-0410-b5e6-96231b3b80d8
Add some tests for __OPTIMIZE_SIZE__ and __NO_INLINE__,
removing the superfluous copies in the target-specific
tests, since it's target-independent.
This uncovered a bug in the handling of -Oz: it would
attempt to store the value 2 in the 1-bit bitfield OptimizeSize,
leaving a value of 0 and never defining __OPTIMIZE_SIZE__.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161495 91177308-0d34-0410-b5e6-96231b3b80d8
This macro was being unconditionally set to zero, preceded by a FIXME comment.
This fixes <rdar://problem/11845441>. Patch by Michael Gottesman!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160491 91177308-0d34-0410-b5e6-96231b3b80d8
This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point operations. Available modes are:
- Fast: Form fused operations anywhere.
- On: Form fused operations where allowed by FP_CONTRACT. This is the default
mode.
- Off: Don't form fused operations (in future this may be relaxed to forming
fused operations where it can be proved that the result won't be
affected).
Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off'
modes are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159794 91177308-0d34-0410-b5e6-96231b3b80d8
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159539 91177308-0d34-0410-b5e6-96231b3b80d8
comparison between two templated types when they both appear in a diagnostic.
Type elision will remove indentical template arguments, which can be disabled
with -fno-elide-type. Cyan highlighting is applied to the differing types.
For more formatting, -fdiagnostic-show-template-tree will output the template
type as an indented text tree, with differences appearing inline. Template
tree works with or without type elision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159216 91177308-0d34-0410-b5e6-96231b3b80d8
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158759 91177308-0d34-0410-b5e6-96231b3b80d8
option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158694 91177308-0d34-0410-b5e6-96231b3b80d8
override whether headers are system headers by checking for prefixes of the
header name specified in the #include directive.
This allows warnings to be disabled for third-party code which is found in
specific subdirectories of include paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158418 91177308-0d34-0410-b5e6-96231b3b80d8
When enabled, clang generates bounds checks for array and pointers dereferences. Work to follow in LLVM's backend.
OK'ed by Chad; thanks for the review.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156431 91177308-0d34-0410-b5e6-96231b3b80d8
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.
Reviewed by Eric Christopher.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156160 91177308-0d34-0410-b5e6-96231b3b80d8
First, this patch cleans up the parsing of the PIC and PIE family of
options in the driver. The existing logic failed to claim arguments all
over the place resulting in kludges that marked the options as unused.
Instead actually walk all of the arguments and claim them properly.
We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the
last one on the commandline. Previously there were lots of ordering bugs
that could creep in due to the nature of the parsing. Let me know if
folks would like weird things such as "-fPIE -fno-pic" to turn on PIE,
but disable full PIC. This doesn't make any sense to me, but we could in
theory support it.
Options that seem to have intentional "trump" status (-static, -mkernel,
etc) continue to do so and are commented as such.
Next, a -pie-level flag is threaded into the frontend, rigged to
a language option, and handled preprocessor, setting up the appropriate
defines. We'll now have the correct defines when compiling with -fpie.
The one place outside of the preprocessor that was inspecting the PIC
level (as opposed to the relocation model, which is set and handled
separately, yay!) is in the GNU ObjC runtime. I changed it to exactly
preserve existing behavior. If folks want to change its behavior in the
face of PIE, they can do that in a separate patch.
Essentially the only functionality changed here is the preprocessor
defines and bug-fixes to the argument management.
Tests have been updated and extended to test all of this a bit more
thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154291 91177308-0d34-0410-b5e6-96231b3b80d8
flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.
Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.
I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153550 91177308-0d34-0410-b5e6-96231b3b80d8
The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.
This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.
This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement.
The option is turned off by default for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153534 91177308-0d34-0410-b5e6-96231b3b80d8
list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153522 91177308-0d34-0410-b5e6-96231b3b80d8
Due to lack of move semantics we would create a temporary std::string from the
string literal, copy it into the vector and discard the temporary. This leads
to massive code bloat, optimizing it saves 50k on i386-linux-Release+Asserts.
While there add a two-element overload for push_back, simplifying code a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153441 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152754 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152660 91177308-0d34-0410-b5e6-96231b3b80d8
We do not reanalyze a function, which has already been analyzed as an
inlined callee. As per PRELIMINARY testing, this gives over
50% run time reduction on some benchmarks without decreasing of the
number of bugs found.
Turning the mode on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152440 91177308-0d34-0410-b5e6-96231b3b80d8
PR12196: The module hash strings are not actually hashing the compiler version
string; the entire version string is being included in the hash. Depending on
the module cache directory name, that can lead to failures where the path
names become too long. As a temporary workaround, just remove the version
string from the hash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152266 91177308-0d34-0410-b5e6-96231b3b80d8
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152141 91177308-0d34-0410-b5e6-96231b3b80d8
command line options for inlining tuning.
This adds the option for stack depth bound as well as function size
bound.
+ minor doxygenification
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151930 91177308-0d34-0410-b5e6-96231b3b80d8
This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151846 91177308-0d34-0410-b5e6-96231b3b80d8
The class name is long enough without the llvm:: added.
Also bring in RefCountedBase and RefCountedBaseVPTR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150958 91177308-0d34-0410-b5e6-96231b3b80d8
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150612 91177308-0d34-0410-b5e6-96231b3b80d8
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149735 91177308-0d34-0410-b5e6-96231b3b80d8
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149679 91177308-0d34-0410-b5e6-96231b3b80d8
like Darwin that don't support it. We should also complain about
invalid -fvisibility=protected, but that information doesn't seem
to exist at the most appropriate time, so I've left a FIXME behind.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149186 91177308-0d34-0410-b5e6-96231b3b80d8
leaves "finalize' behind and in arc mode, does not
include it. This allows the migrated source to be compiled
in both gc and arc mode. // rdar://10532441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149079 91177308-0d34-0410-b5e6-96231b3b80d8
provide the layout of records, rather than letting Clang compute
the layout itself. LLDB provides the motivation for this feature:
because various layout-altering attributes (packed, aligned, etc.)
don't get reliably get placed into DWARF, the record layouts computed
by LLDB from the reconstructed records differ from the actual layouts,
and badness occurs. This interface lets the DWARF data drive layout,
so we don't need the attributes preserved to get the answer write.
The testing methodology for this change is fun. I've introduced a
variant of -fdump-record-layouts called -fdump-record-layouts-simple
that always has the simple C format and provides size/alignment/field
offsets. There is also a -cc1 option -foverride-record-layout=<file>
to take the output of -fdump-record-layouts-simple and parse it to
produce a set of overridden layouts, which is introduced into the AST
via a testing-only ExternalASTSource (called
LayoutOverrideSource). Each test contains a number of records to lay
out, which use various layout-changing attributes, and then dumps the
layouts. We then run the test again, using the preprocessor to
eliminate the layout-changing attributes entirely (which would give us
different layouts for the records), but supplying the
previously-computed record layouts. Finally, we diff the layouts
produced from the two runs to be sure that they are identical.
Note that this code makes the assumption that we don't *have* to
provide the offsets of bases or virtual bases to get the layout right,
because the alignment attributes don't affect it. I believe this
assumption holds, but if it does not, we can extend
LayoutOverrideSource to also provide base offset information.
Fixes the Clang side of <rdar://problem/10169539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149055 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149027 91177308-0d34-0410-b5e6-96231b3b80d8
specific to migrator. Use its first option to
warn migrating from GC to arc when
NSAllocateCollectable/NSReallocateCollectable is used.
// rdar://10532541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148887 91177308-0d34-0410-b5e6-96231b3b80d8
the front end into its own class, FrontendInputFile, to make it easier
to introduce new per-input data. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148546 91177308-0d34-0410-b5e6-96231b3b80d8
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147447 91177308-0d34-0410-b5e6-96231b3b80d8
Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.
This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.
I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.
I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147434 91177308-0d34-0410-b5e6-96231b3b80d8
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147221 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147218 91177308-0d34-0410-b5e6-96231b3b80d8
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146297 91177308-0d34-0410-b5e6-96231b3b80d8
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145444 91177308-0d34-0410-b5e6-96231b3b80d8
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.
Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.
The -ftemplate-depth=N part of this fixes PR9890.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145045 91177308-0d34-0410-b5e6-96231b3b80d8
a bug where the reference count is copied in the copy constructor, which means that there were cases when the CompilerInvocation
objects created by ASTUnit were actually leaked. When I fixed that bug locally, it showed that a whole bunch of code assumed
that the LangOptions object that was part of CompilerInvocation was still alive. By making it heap-allocated and reference counted,
we can keep it around after the CompilerInvocation object goes away.
As part of this change, change CompilerInvocation:getLangOptions() to return a pointer, acting as another clue that this
object may outlive the CompilerInvocation object.
This commit doesn't fix the CompilerInvocation leak itself. That will come when I commit the fix to llvm::RefCountedBase<T> to
mainline LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144930 91177308-0d34-0410-b5e6-96231b3b80d8
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143917 91177308-0d34-0410-b5e6-96231b3b80d8
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143801 91177308-0d34-0410-b5e6-96231b3b80d8
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143798 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.
I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.
More work to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143259 91177308-0d34-0410-b5e6-96231b3b80d8
r142300 but not this patch, clang -S may emit .s files that assemblers other
than llvm-mc can't parse.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142301 91177308-0d34-0410-b5e6-96231b3b80d8
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142187 91177308-0d34-0410-b5e6-96231b3b80d8
This frontend-only flag is used by the IR generator to determine
whether to filter CUDA declarations for the host or for the device.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141301 91177308-0d34-0410-b5e6-96231b3b80d8
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140957 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the existing code for CPATH into the driver and adds the environment lookup and path splitting there.
The paths are then passed down to cc1 with -I options (CPATH), added after the normal user-specified include dirs.
Language specific paths are passed via -LANG-isystem and the actual filtering is performed in the frontend.
I tried to match GCC's behavior as close as possible
Fixes PR8971.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140341 91177308-0d34-0410-b5e6-96231b3b80d8
Eric Christopher