that just uses the new toolchain probing logic. This fixes linking with -m32 on
64 bit systems (the /32 dir was not being added to the search).
llvm-svn: 149652
into using non-absolute system includes (<foo>)...
... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.
As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.
llvm-svn: 149611
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too. (clang r149497 / llvm r149498)
Also include the config.h header after all other headers, per
the LLVM coding standards.
It also turns out WindowsToolChain.cpp wasn't using the config
header at all, so that include's just deleted now.
llvm-svn: 149504
builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.
llvm-svn: 149434
for getting the name of the module file, unifying the code for
searching for a module with a given name (into lookupModule()) and
separating out the mapping to a module file (into
getModuleFileName()). No functionality change.
llvm-svn: 149197
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.
llvm-svn: 149186
single attribute ("system") that allows us to mark a module as being a
"system" module. Each of the headers that makes up a system module is
considered to be a system header, so that we (for example) suppress
warnings there.
If a module is being inferred for a framework, and that framework
directory is within a system frameworks directory, infer it as a
system framework.
llvm-svn: 149143
-Wno-everything remap all warnings to ignored.
We can now use "-Wno-everything -W<warning>" to ignore all warnings except
specific ones.
llvm-svn: 149121
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
llvm-svn: 149079
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>.
llvm-svn: 149055
-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.
llvm-svn: 149027
return pre-built lists. Instead, it feeds the methods it deserializes
to Sema so that Sema can unique them, which keeps the chains shorter.
llvm-svn: 148889
specific to migrator. Use its first option to
warn migrating from GC to arc when
NSAllocateCollectable/NSReallocateCollectable is used.
// rdar://10532541
llvm-svn: 148887
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
in the module map. This provides a bit more predictability for the
user, as well as eliminating the need to sort the submodules when
serializing them.
llvm-svn: 147564
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.
llvm-svn: 147447
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.
llvm-svn: 147434
features needed for a particular module to be available. This allows
mixed-language modules, where certain headers only work under some
language variants (e.g., in C++, std.tuple might only be available in
C++11 mode).
llvm-svn: 147387
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
llvm-svn: 147218
hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.
Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.
llvm-svn: 146933
It had been causing test "Misc/diag-verify.cpp" failure on ms cl.exe. The emission was ordered unexpectedly as below;
First) error: 'error' diagnostics seen but not expected:
Second) error: 'error' diagnostics expected but not seen:
llvm-svn: 146830
the policy of how diagnostics are lowered/rendered, while TextDiagnostic handles
the actual pretty-printing.
This is a first part of reworking SerializedDiagnosticPrinter to use the same
inclusion-stack/macro-expansion logic as TextDiagnostic.
llvm-svn: 146819
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.
llvm-svn: 146749
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
belonged in the Serialization library, it's setting up a compilation,
not just deserializing.
This should fix PR11512, making Serialization actually be layered below
Frontend, a long standing layering violation in Clang.
llvm-svn: 146233
part of HeaderSearch. This function just normalizes filenames for use
inside of a synthetic include directive, but it is used in both the
Frontend and Serialization libraries so it needs a common home.
llvm-svn: 146227
umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
part of the module with that umbrella directory. However, unlike
umbrella headers, which are expected to include all of the headers
within their subdirectories, Clang will automatically include all of
the headers it finds in the named subdirectory.
The intent here is to allow a module map to trivially turn a
subdirectory into a module, where the module's structure can mimic the
directory structure.
llvm-svn: 146165
header to also support umbrella directories. The umbrella directory
for an umbrella header is the directory in which the umbrella header
resides.
No functionality change yet, but it's coming.
llvm-svn: 146158
-Allow it to be used with multiple BeginSourceFile/EndSourceFile calls; for this introduce
a "finish" callback method in the DiagnosticConsumer. SDiagsWriter finishes up the serialization
file inside this method.
-Make it independent of any particular DiagnosticsEngine; make it use the SourceManager of the
Diagnostic object.
-Ignore null source ranges.
llvm-svn: 146020
explicit submodules or umbrella headers from submodules. Instead,
build the entire module at once, and let the name-hiding mechanisms
hide the contents of explicit submodules at load time.
llvm-svn: 145940
(sub)module, all of the names may be hidden, just the macro names may
be exposed (for example, after the preprocessor has seen the import of
the module but the parser has not), or all of the names may be
exposed. Importing a module makes its names, and the names in any of
its non-explicit submodules, visible to name lookup (transitively).
This commit only introduces the notion of name visible and marks
modules and submodules as visible when they are imported. The actual
name-hiding logic in the AST reader will follow (along with test cases).
llvm-svn: 145586
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).
llvm-svn: 145538
submodules. This information will eventually be used for name hiding
when dealing with submodules. For now, we only use it to ensure that
the module "key" returned when loading a module will always be a
module (rather than occasionally being a FileEntry).
llvm-svn: 145497
check whether the named submodules themselves are actually
valid, and drill down to the named submodule (although we don't do
anything with it yet). Perform typo correction on the submodule names
when possible.
llvm-svn: 145477
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.
llvm-svn: 145310
inside an objc container that "contains" other file-level declarations.
When getting the array of file-level declarations that overlap with a file region,
we failed to report that the region overlaps with an objc container, if
the container had other file-level declarations declared lexically inside it.
Fix this by marking such declarations as "isTopLevelDeclInObjCContainer" in the AST
and handling them appropriately.
llvm-svn: 145109
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.
llvm-svn: 145045
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.
llvm-svn: 144930
header, create our own in-memory buffer to parse all of the
appropriate headers, and use that to build the module. This isn't
end-to-end testable yet; that's coming next.
llvm-svn: 144797
warnings/errors for unknown warning options. getDiagnosticsInGroup returns false if the
diagnostics is found and true otherwise. Thus, if we're reporting and we have a valid
diagnostic, we were actually setting the flag and causing mayhem.
rdar://10444207
llvm-svn: 144670
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.
llvm-svn: 143917
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
llvm-svn: 143822
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.
llvm-svn: 143801
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.
llvm-svn: 143798
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
llvm-svn: 143752
A PCH file keeps track of #pragma diagnostics state; when loading the preamble, they conflicted
with the #pragma diagnostic state already present in the DiagnosticsEngine object due to
parsing the preamble.
Fix this by clearing the state of the DiagnosticsEngine object.
Fixes rdar://10363572 && http://llvm.org/PR11254.
llvm-svn: 143644
This is intended for direct access of the ASTReader for uses that make
little sense to try to shoehorn in the ExternalASTSource interface.
llvm-svn: 143465
because we don't want to take this performance hit when doing code completion
Log of r143342:
Move caching of code-completion results from ASTUnit::Reparse to ASTUnit::CodeComplete,
so that it will happen when we are doing code-completion, not reparsing.
llvm-svn: 143367
search logic. The Debian multiarch seems to have completely changed from
when these were originally added, and I'd like to remove a bunch of
them, but I'll be lazy and delay that until this logic is hoisted into
the driver where it belongs.
This should resolve PR11223.
llvm-svn: 143345
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.
llvm-svn: 143259
preprocessed entities that are #included in the range that we are interested.
This is useful when we are interested in preprocessed entities of a specific file, e.g
when we are annotating tokens. There is also an optimization where we cache the last
result of PreprocessingRecord::getPreprocessedEntitiesInRange and we re-use it if
there is a call with the same range as before.
rdar://10313365
llvm-svn: 142887
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.
llvm-svn: 142187
formatting as any other diagnostic, they will be properly line wrapped and
otherwise pretty printed. Let's take advantage of that and the new factoring to
add some helpful information to them (much like template backtrace notes and
other notes): the name of the macro whose expansion is being noted. This makes
a world of difference if caret diagnostics are disabled, making the expansion
notes actually useful in this case. It also helps ensure that in edge cases the
information the user needs is present. Consider:
% nl -ba t5.cc
1 #define M(x, y, z) \
2 y
3
4 M(
5 1,
6 2,
7 3);
We now produce:
% ./bin/clang -fsyntax-only t5.cc
t5.cc:6:3: error: expected unqualified-id
2,
^
t5.cc:2:3: note: expanded from macro: M
y
^
1 error generated.
Without the added information in the note, the name of the macro being expanded
would never be shown.
This also deletes a FIXME to use the diagnostic formatting. It's not yet clear
to me that we *can* do this reasonably, and the production of this message was
my primary goal here anyways.
I'd love any comments or suggestions on improving these notes, their wording,
etc. Currently, I need to make them provide more helpful information in the
presence of a token-pasting buffer, and I'm pondering adding something along
the lines of "expanded from argument N of macro: ...".
llvm-svn: 142127
this long quest: actually use the note printing machinery for each macro
expansion note rather than a hacky version of it. This will colorize and
format the notes the same as any other. There is still some stuff to fix
here, but it's one step closer.
No test case changes because currently we don't do anything differently
that I can FileCheck for -- I don't really want to try matching the
color escape codes... Suggestions for how to test this are welcome. =]
llvm-svn: 142121
standing deficiency: we were providing no macro backtrace information
whenever caret diagnostics were turned off. This sinks the logic for
suppressing the code snippet and caret to the code that actually prints
tho code snippet and caret. Along the way, clean up the naming of
functions, remove some now fixed FIXMEs, and generally improve the
wording and logic of this process.
Add a test case exerecising this functionality. It is notable that the
resulting messages are extremely low quality. I'm working on a follow-up
patch that should address this and have left a FIXME in the test case.
llvm-svn: 142120
the SourceManager doesn't change, and the source files don't change.
This greatly simplifies the interfaces and interactions. The lifetime of
the TextDiagnostic object forms the 'session' over which we attempt to
condense and deduplicate information in diagnostics.
llvm-svn: 142104
been there. Also delete their redundant doxyments in favor of those in
the source file. I'm putting the doxyments for private and static
helpers into the implementation file, and only the public interface
doxyments into the header. If folks have strong opinions about this type
of split, feel free to chime in, I'm happy to re-organize.
llvm-svn: 142087
making it accessible to anyone from the Frontend library. Still a good
bit of cleanup to do here, but its a good milestone. This ensures that
*all* of the functionality needed to implement the DiagnosticConsumer is
exposed via the generic interface in some form. No sneaky re-use of
static functions.
llvm-svn: 142086
diagnostics to control suppression of redundant information. It now
follows the same model as all the other state, and has a bit more clear
semantics.
This is making the duality of the state a bit annoying, and I've added
a FIXME to resolve it. The problem is that I need to lift the
TextDiagnostic up into an externally visible layer before that can
happen.
llvm-svn: 142083
TextDiagnosticPrinter argument to the TextDiagnostic helper class. This
cements the proper ordering of things: TextDiagnostic is now a viable
stand-alone class for emitting pretty-printed textual diagnostics to
a terminal.
llvm-svn: 142070
utility. This is a particularly nice win because it removes a pile of
parameters from these routines. Also name them a bit better. I'm trying
to follow the pattern of 'emit' routines writing directly to what is
expected to be the final output, while 'print' routines take a output
stream argument and can be used to build up intermediate buffers, etc.
Also, fix a bug I spotted by inspection from my last commit where
'LastLoc' and 'LastNonNoteLoc' were reversed. It's really scary that
this didn't trigger a single test failure. Will be working on tests for
more of this functionality now.
llvm-svn: 142069
across emissions.
1) The include stack printing is conditioned on non-note diagnostics,
not just on warning diagnostics.
2) Those should be full source locations as they're tied to a source
manager.
3) We should pass in the prior state to the TextDiagnostic constructor,
allow it to mutate as diagnostics are emitted, and then cache the
final state before tearing it down.
Some of this remains incomplete, specifically #3 isn't finished for the
non-note location. That'll come when the include stack printing sinks
down a level.
This also highlights how *completely* bug-ridden this code is. For
example, we currently do all these comparisons of a FullSourceLoc and
a SourceLocation... which silently does a SourceLocation to
SourceLocation comparison, completely disregarding the source manager
from whence one of the arguments came. Oops! Good thing in practice this
wasn't important, but it could in theory be suppressing caret
diagnostics in a second TU on a single clang invocation. I'm hoping to
hammer these bugs out as the refactorings occur, although for so many of
them it's really unlikely I can dream up a test case that would show the
potentially buggy behavior.
llvm-svn: 142067
consumer. The TextDiagnostic interface now has a generic entry point for
emitting a diagnostic which uses a minimal interface that should be
compatible with StoredDiagnostics such as are available in libclang etc.
Some unfortunate shuffling of static functions as things get relocated.
Also some unfortunate public interface points added to
TextDiagnosticPrinter, but those are the next bits to get moved so they
won't last long.
llvm-svn: 142064
to operate directly on the source location and ranges associated with
a diagnostic rather than digging them out of the diagnostic. This had
a side benefit of cleaning up its code a tiny bit by using the ArrayRef
interface.
No functionality changed.
llvm-svn: 142063
Also note that it is actually doing much more than it should. This paves
the way for building a more generic 'Emit' routine that is the real
entry point here.
llvm-svn: 142035
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.
llvm-svn: 141179
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.
llvm-svn: 140957
- The TextDiagnosticPrinter code is still fragile as it is just "reverse engineering" what the diagnostic engine is doing. Not my current priority to fix though.
llvm-svn: 140752
DiagnosticsEngine::setDiagnosticGroup{ErrorAsFatal,WarningAsError} methods which
more accurately model the correct API -- no internal change to the diagnostics
engine yet though.
- Also, stop honoring -Werror=everything (etc.) as a valid (but oddly behaved) option.
llvm-svn: 140747
we have the ability to create a new, distict diagnostic consumer when
we go off and build a module. This avoids the currently horribleness
where the same diagnostic consumer sees diagnostics for multiple
translation units (and multiple SourceManagers!) causing all sorts of havok.
llvm-svn: 140743
message. Specifically, we now only line-wrap the first line of te
diagnostic message and assume the remainder is manually formatted. While
adding it back, simplify the logic for doing this.
Finally, add a test that ensures we actually preserve this feature. =D
*Now* its not dead code. Thanks to Doug for the test case.
llvm-svn: 140538
when working with a diagnostic attached to a source location. Also
comment more thoroughly why its important to handle non-location
diagnostic messages separately.
Finally, hoist the creation of the TextDiagnostic object up to the
beginning of the location-based diagnostics. This paves the way for
sinking more and more of the logic into this class. When everything
below this constructor is sunk into the TextDiagnostic class it should
be sufficiently "feature complete" to accomplish my two goals:
1) Have the printing of a macro expansion note use the exact same code
as any other note.
2) Be able to implement clang_formatDiagnostic in terms of this class.
llvm-svn: 140526
a dedicated path. The logic for such diagnostics is much simpler than
for others.
This begins to make an important separation in this routine. We expect
most (and most interesting) textual diagnostics to be made in the
presence of at least *some* source locations and a source manager.
However the DiagnosticConsumer must be prepared to diagnose errors even
when the source manager doesn't (yet) exist or when there is no location
information at all. In order to sink more and more logic into the
TextDiagnostic class while minimizing its complexity, my plan is to
force the DiagnosticConsumer to special case diagnosing any locationless
messages and then hand the rest to the TextDiagnostic class. I'd
appreciate any comments on this design. It requires a bit of code
duplication in order to keep interfaces simple. Alternatively, if we
really need TextDiagnostic to be capable of handling diagnostics even in
the absence of a viable SourceManager, then this split isn't necessary.
llvm-svn: 140525
function. Doing this conveniently requires moving the word wrapping to
use a StringRef which seems generally an improvement. There is a lot
that could be simplified in the word wrapping by using StringRef that
I haven't looked at yet...
llvm-svn: 140524
a "loaded" location of the precompiled preamble.
Instead, handle specially locations of preprocessed entities:
-When looking up for preprocessed entities, map main file locations inside the
preamble range to a preamble loaded location.
-When getting the source range of a preprocessing cursor, map preamble loaded
locations back to main file locations.
Fixes rdar://10175093 & http://llvm.org/PR10999
llvm-svn: 140519
characters. I could find no newline character in a diagnostic message,
and adding an assert to this code never fires in the testsuite.
I think this code is essentially dead, and was previously used for
a different purpose. If I just don't understand how it is we can end up
with a newline here please let me know (with a test case?) and I'll
revert.
llvm-svn: 140497
to handle non-caret diagnostics as well in order to be fully useful in
libclang etc. Also sketch out some more of my plans on this refactoring.
llvm-svn: 140476
tracking the start and stop of macro expansion suppression. Also remove
the Columns variable which was just a convenience variable based on
DiagOpts. Instead we materialize it in the one piece of code that cared.
llvm-svn: 140475
TextDiagnosticPrinter into the CaretDiagnostic class. Several
interesting results from this:
- This removes a significant per-diagnostic bit of state from the
CaretDiagnostic class, which should eventually allow us to re-use the
object.
- It removes a redundant recursive walk of the macro expansion stack
just to compute the depth. We don't need the depth until we're
unwinding anyways, so we can just mark when we reach it.
- It also paves the way for several simplifications we can do to how we
implement the suppression.
llvm-svn: 140474
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.
llvm-svn: 140341
OpenCL is different from AltiVec in the way it supports vector literals. OpenCL
is strict with regards to semantic checks. For example, implicit conversions
and explicit casts between vectors of different types are disallowed.
Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140270
PreprocessingRecord's getPreprocessedEntitiesInRange.
Also remove all the stuff that were added in ASTUnit that are unnecessary now
that we do a binary search for preprocessed entities and deserialize only
what is necessary.
llvm-svn: 140063
check whether the requested location points inside the precompiled preamble,
in which case the returned source location will be a "loaded" one.
llvm-svn: 140060
Microsoft specific tweaking will now fall into 2 categories:
- fms-extension: Microsoft specific extensions that should never change the meaning of an otherwise well formed code. Currently map to LangOptions::Microsoft. (To be clearer, I am planning to change the name to LangOptions::MicrosoftExt).
- fms-compatibility: Really a MSVC emulation mode. Map to LangOptions::MicrosoftMode. Can change the meaning of an otherwise standard conformant program.
llvm-svn: 139978
-Use an array of offsets for all preprocessed entities
-Get rid of the separate array of offsets for just macro definitions;
for references to macro definitions use an index inside the preprocessed
entities array.
-Deserialize each preprocessed entity lazily, at first request; not in bulk.
Paves the way for binary searching of preprocessed entities that will offer
efficiency and will simplify things on the libclang side a lot.
llvm-svn: 139809
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.
llvm-svn: 139662
language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
llvm-svn: 139605
already provided. This required a little bit of clean-up in the way
that VerifyDiagnosticsClient managed ownership of its underlying
"primary" client, because now it will no longer always take ownership.
llvm-svn: 139570
but there is a corresponding umbrella header in a framework, build the
module on-the-fly so it can be immediately loaded at the import
statement. This is very much proof-of-concept code, with details to be
fleshed out over time.
llvm-svn: 139558
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.
llvm-svn: 139538
modifying directly for the preamble.
This avoids an awful, hard to find, bug where "PreprocessorOpts.DisablePCHValidation = true"
would be persistent for subsequent reparses of the translation unit which would result
in defines, present in command-line but not in the PCH, being ignored.
Fixes rdar://9615399.
llvm-svn: 139512
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
llvm-svn: 139404
function. This is really the beginning of the second phase of
refactorings here. The end goal is to have (roughly) three interfaces:
1) Base class to format a single diagnostic suitable for display on the
console.
2) Extension of the base class which also displays a caret diagnostic
suitable for display on the console.
3) An adaptor that implements the DiagnosticClient by delegating to #1
and/or #2 as appropriate.
Once we have these, things like libclang's formatDiagnostic can use #1
and #2 to provide really well formatted (and consistently formatted!)
textual formatting of diagnostics.
Getting there is going to be quite a bit of shuffling. I'm basically
sketching out where the interface boundaries can be drawn for #1 and #2
within the existing classes. That lets me shuffle with a minimum of fuss
and delta. Once that's done, and any of the related interfaces that need
to change are updated, I'll hoist these into separate headers and
re-implement libclang in terms of their interfaces. Long WIP, but
comments at each step welcome. =D
llvm-svn: 139228
a stack array of a magical size with an assert() that we never
overflowed it. That seems incredibly risky. We also have a very nice API
for bundling up a vector we expect to usually have a small size without
loss of functionality or security if the size is excessive.
The fallout is to remove the last pointer+size parameter pair that are
traced through the recursive caret diagnostic emission.
llvm-svn: 139217
a defined interface. This isn't as nice as the previous one, but should
get better as I push through better data types in all these functions.
Also, I'm hoping to pull some aspects of this out into a common routine
(such as tab expansion).
Again, WIP, comments welcome as I'm going through.
llvm-svn: 139190
The function was only counting lines that included tokens and not empty lines,
but MaxLines (mainly initiated to the line where the code-completion point resides)
is a count of overall lines (even empty ones).
llvm-svn: 139085
Preprocessor, eliminating the constructor that was used by ASTUnit
(which didn't provide an ASTContext or Prepreprocessor). Ensuring that
both objects are non-NULL will simplify module loading (but none of
that is done yet).
llvm-svn: 138986
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
and language-specific initialization. Use this to allow ASTUnit to
create a preprocessor object *before* loading the AST file. No actual
functionality change.
llvm-svn: 138983
LangOptions, rather than making distinct copies of
LangOptions. Granted, LangOptions doesn't actually get modified, but
this will eventually make it easier to construct ASTContext and
Preprocessor before we know all of the LangOptions.
llvm-svn: 138959
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
(unsurprisingly) caret diagnostics. This is designed to bring some
organization to the monstrous EmitCaretDiagnostic function, and allow
factoring it more easily and with less mindless parameter passing.
Currently this just lifts the existing function into a method, and
splits off the obviously invariant arguments to be class members. No
functionality is changed, and there are still lots of warts to let
existing code continue functioning as-is. Definitely WIP, more cleanups
to follow.
llvm-svn: 138921
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
from the given source. -emit-module behaves similarly to -emit-pch,
except that Sema is somewhat more strict about the contents of
-emit-module. In the future, there are likely to be more interesting
differences.
llvm-svn: 138595
Currently this includes -pedantic warnings as well; we'll need to consider whether these should
be included.
This works as expected with -Werror.
Test cases were added to Sema/warn-unused-parameters.c, but they should probably be broken off into
their own test file.
llvm-svn: 137910
all AST files have a normal METADATA record that has the same form
regardless of whether we refer to a chained PCH or any other kind of
AST file.
Introduce the IMPORTS record, which describes all of the AST files
that are imported by this AST file, and how (as a module, a PCH file,
etc.). Currently, we emit at most one entry to this record, to support
chained PCH.
llvm-svn: 137869
already-defined and forward-declared results. Already-defined results
are fine because they could be the start of a category. Fixes
<rdar://problem/9811691>.
llvm-svn: 136559
For PCH files, have only one open/close for temporary + rename to be safe from race conditions.
For all other output files open/close the output file directly.
Depends on llvm r136310. rdar://9082880 & http://llvm.org/PR9374.
llvm-svn: 136315
FullSourceLoc::getInstantiationLoc to ...::getExpansionLoc. This is part
of the API and documentation update from 'instantiation' as the term for
macros to 'expansion'.
llvm-svn: 135914
entities generated directly by the preprocessor from those loaded from
the external source (e.g., the ASTReader). By separating these two
sets of entities into different vectors, we allow both to grow
independently, and eliminate the need for preallocating all of the
loaded preprocessing entities. This is similar to the way the recent
SourceManager refactoring treats FileIDs and the source location
address space.
As part of this, switch over to building a continuous range map to
track preprocessing entities.
llvm-svn: 135646
-arcmt-migrate-emit-errors : Emits the pre-migration ARC errors but it doesn't affect anything else
-arcmt-migrate-report-output : Writes out the pre-migration ARC errors to the provided plist file
rdar://9791454
llvm-svn: 135491
source locations from source locations loaded from an AST/PCH file.
Previously, loading an AST/PCH file involved carefully pre-allocating
space at the beginning of the source manager for the source locations
and FileIDs that correspond to the prefix, and then appending the
source locations/FileIDs used for parsing the remaining translation
unit. This design forced us into loading PCH files early, as a prefix,
whic has become a rather significant limitation.
This patch splits the SourceManager space into two parts: for source
location "addresses", the lower values (growing upward) are used to
describe parsed code, while upper values (growing downward) are used
for source locations loaded from AST/PCH files. Similarly, positive
FileIDs are used to describe parsed code while negative FileIDs are
used to file/macro locations loaded from AST/PCH files. As a result,
we can load PCH/AST files even during parsing, making various
improvemnts in the future possible, e.g., teaching #include <foo.h> to
look for and load <foo.h.gch> if it happens to be already available.
This patch was originally written by Sebastian Redl, then brought
forward to the modern age by Jonathan Turner, and finally
polished/finished by me to be committed.
llvm-svn: 135484
This is switches all the interfaces points (and most of the commenst
/ local variables I saw on my way through) regarding the
NestedMacroInstantiations bit.
The libclang enums corresponding to this state were renamed, but
a legacy enum was added with the old name, and the same value to keep
existing clients working. I've added a documentation blurb for it, but
let me know if there is a canonical way to document legacy elemenst of
the libclang interface.
No functionality changed here, even in tests.
llvm-svn: 135141
and 'expansions' rather than 'instantiated' and 'contexts'.
This is the first of several patches migrating Clang's terminology
surrounding macros from 'instantiation' to 'expansion'.
llvm-svn: 135135
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
llvm-svn: 135051
This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.
<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.
Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.
Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.
rdar://9735086.
llvm-svn: 134844
instantiation and improve diagnostics which are stem from macro
arguments to trace the argument itself back through the layers of macro
expansion.
This requires some tricky handling of the source locations, as the
argument appears to be expanded in the opposite direction from the
surrounding macro. This patch provides helper routines that encapsulate
the logic and explain the reasoning behind how we step through macros
during diagnostic printing.
This fixes the rest of the test cases originially in PR9279, and later
split out into PR10214 and PR10215.
There is still some more work we can do here to improve the macro
backtrace, but those will follow as separate patches.
llvm-svn: 134660
clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!
llvm-svn: 134615
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
CompilerInvocation on the stack, because other objects (e.g., the
CompilerInstance) maintain an intrusive reference-counted pointer to
the CompilerInvocation. This doesn't matter in the normal case,
because we take back the CompilerInvocation. However, during crash
recovery, this leads to us trying to free an object on the stack, and
hilarity ensues. Fixes <rdar://problem/9652540>.
llvm-svn: 134245
This is a one line fix here:
+ // Don't print recursive instantiation notes from an instantiation note.
+ Loc = SM.getSpellingLoc(Loc);
While here, fix the testcase to be more precise (it got filecheck'ized
brutally), and fix EmitCaretDiagnostic to be private and to not pass down
the unused 'Level' argument.
llvm-svn: 133993
This is the only usage in clang's headers, and it's for a define
that only exists on CMake builds for the sake of the MSVC compiler,
so just use an ifdef instead.
Also add an include for config.h in a file that actually needs it,
and was picking it up by accident indirectly.
llvm-svn: 133710
use an "IgnoreSysRoot" argument. HeaderSearchOptions had been using the
opposite form with "IsSysRootRelative", which made for much confusion when
looking at true/false values in calls in AddPath. No functional change.
llvm-svn: 133550
The -cxx-isystem path is not prefixed with the sysroot directory, so it's
not a good way for the driver to set the system default C++ search path.
Instead, add -stdlib as a cc1 option and teach the frontend how to find the
headers. The driver can then just pass -stdlib through to "cc1".
llvm-svn: 133547
- Changes bit-field access policy to try to use (aligned) register sized accesses.
The idea here is that by using larger accesses we expose more coalescing
potential to the backend when we have situations like adjacent bit-fields in the
same structure (which is common), and that the backend should be smart enough to
narrow the accesses down when no coalescing is done or when it is shown not to
be profitable.
--
$ clang -m32 -O3 -S -o - t.c
_f0: ## @f0
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movb (%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, (%eax)
movb 1(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 1(%eax)
movb 2(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 2(%eax)
movb 3(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 3(%eax)
popl %ebp
ret
$ clang -m32 -O3 -S -o - t.c -Xclang -fuse-register-sized-bitfield-access
_f0: ## @f0
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movl $-2139062144, %ecx ## imm = 0xFFFFFFFF80808080
andl (%eax), %ecx
orl $16843009, %ecx ## imm = 0x1010101
movl %ecx, (%eax)
popl %ebp
ret
--
llvm-svn: 133532
an assembly file it worked correctly, while for a .c file it would given an
error about how --noexecstack is not a supported argument to -Wa.
llvm-svn: 133489
because the Angled directories and the System directories were not being uniqued
together, breaking #include_next. I'll see about a testcase, but it will be insane.
llvm-svn: 133212
These are somewhat special in that they wrap any other FrontendAction,
running various ARC transformations or checks prior to the standard
action's run. To implement them easily, this extends FrontendAction to
have a WrapperFrontendAction utility class which forwards all calls by
default to an inner action setup at construction time. This is then
subclassed to override the specific behavior needed by the different
ARCMT tools.
Finally, FrontendTool is taught how to create these wrapper actions from
the existing flags and options structures.
The result is that clangFrontend no longer depends on clangARCMigrate.
This is very important, as clangARCMigrate *heavily* depends on
clangFrontend. Fundamentally ARCMigrate is at the same layer as
a library like Rewrite, sitting firmly on top of the Frontend, but tied
together with the FrontendTool when building the clang binary itself.
llvm-svn: 133161
AFAIK, RHEL5 (and its clones) provides g++44 as the package "gcc44-c++".
By default, g++-4.1.1 is available, though, its libstdc++ would not be suitable to clang++.
llvm-svn: 133156
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
Rafael Espindola