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
Anna Zaks