| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 200845
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In TokenLexer::ExpandFunctionArguments(), CurTok.hasLeadingSpace() is
checked in multiple locations, each time subtly differently. Checking it
early, when the token is seen, and using NextTokGetsSpace exclusively
after that makes the code simpler.
No change in behaviour is intended.
Patch by Harald van Dijk!
llvm-svn: 200788
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a macro expansion does not result in any tokens, and the macro name
is preceded by whitespace, the whitespace should be passed to the first
token that follows the macro expansion. Similarly when a macro expansion
ends with a placemarker token, and that placemarker token is preceded by
whitespace. This worked already for top-level macro expansions, but is
now extended to also work for nested macro expansions.
Patch by Harald van Dijk!
llvm-svn: 200787
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a function-like macro definition ends with one of the macro's
parameters, and the argument is empty, any whitespace before the
parameter name in the macro definition needs to be preserved. Promoting
the existing NextTokGetsSpace to a preserved bit-field and checking it
at the end of the macro expansion allows it to be moved to the first
token following the macro expansion result.
Patch by Harald van Dijk!
llvm-svn: 200786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In x ## y, where x and y are regular tokens, whitespace between x and ##
is ignored, and whitespace between ## and y is also ignored. When either
x or y is a function argument, whitespace was preserved, but it should
not be. This patch removes the checks for whitespace before ## and
before y, and in the special case where x is an empty macro argument and
y is a regular token, actively removes whitespace before y.
One existing test is affected by that change, but as clang's output now
matches the standard's requirements and that of GCC, I've tweaked the
testcase.
Patch by Harald van Dijk!
llvm-svn: 200785
|
| |
|
|
|
|
|
| |
just storing a flag indicating if there was one), and include it in the 'end of
module' annotation. No functionality change.
llvm-svn: 200573
|
| |
|
|
|
|
|
| |
This is causing a failure in the msan buildbot that I am having trouble
reproducing. Reverting until I can figure out what went wrong.
llvm-svn: 200492
|
| |
|
|
|
|
|
| |
In particular, #pragma clang __debug, and #include implicitly changed
into @import were causing assertion failures.
llvm-svn: 200475
|
| |
|
|
| |
llvm-svn: 200265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the last incorrect uses and templatize the function to require a
compile-time constant string preventing further misuse.
The diagnostic formatter expects well-formed input and has undefined behaviour
with arbitrary input or crafted user strings in source files. Accepting user
input would also have caused unbounded generation of new diagnostic IDs which
can be problematic in long-running sessions or language bindings.
This completes the work to fix several incorrect callers that passed user
input or raw messages to the diagnostics engine where a constant format string
was expected.
llvm-svn: 200132
|
| |
|
|
|
|
|
|
|
|
| |
This C++ feature has been marked complete since r191549, but the documentation
claimed it wasn't supported at all and the extension check misreported it as
being available in C.
No regression test; this was a short-lived typo.
llvm-svn: 199292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
|
| |
|
|
|
|
| |
whether an ARM target has the "interrupt" attribute, it will return true for ARM and MSP430 targets, and false for others.
llvm-svn: 198897
|
| |
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
| |
|
|
|
|
|
| |
Includes a fix for a missing highlight range caused by a ',' typo in the PP
diagnostics.
llvm-svn: 198252
|
| |
|
|
|
|
|
|
|
|
| |
This is approaching consistency but the PP and Parse categories they still have
slightly different wording:
def err_pp_expected_after : Error<"missing %1 after %0">;
def err_expected_after : Error<"expected %1 after %0">;
llvm-svn: 198189
|
| |
|
|
| |
llvm-svn: 198083
|
| |
|
|
|
|
| |
Follows algorithm described here: http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx
llvm-svn: 198082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce proper facilities to render token spellings using the diagnostic
formatter.
Replaces most of the hard-coded diagnostic messages related to expected tokens,
which all shared the same semantics but had to be multiply defined due to
variations in token order or quote marks.
The associated parser changes are largely mechanical but they expose
commonality in whole chunks of the parser that can now be factored away.
This commit uses C++11 typed enums along with a speculative legacy fallback
until the transition is complete.
Requires corresponding changes in LLVM r197895.
llvm-svn: 197972
|
| |
|
|
|
|
| |
intentional stack overflow.
llvm-svn: 197849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a header file belonging to a certain module is not found on the
filesystem, that header gets marked as unavailable. Now, the layering
warning (-fmodules-decluse) should still warn about headers of this
module being wrongfully included. Currently, headers belonging to those
modules are just treated as not belonging to modules at all which means
they can be included freely from everywhere.
To implement this (somewhat) cleanly, I have moved most of the layering
checks into the ModuleMap. This will also help with showing FixIts
later.
llvm-svn: 197805
|
| |
|
|
| |
llvm-svn: 197695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
This works towards the long-term goal of not stat'ing the header files at all
while reading the module map and instead read them only when the module is
being built (there is a corresponding FIXME in parseHeaderDecl()). However, it
seems non-trivial to get there and this unblock us and moves us into the right
direction.
Also changed the implementation to reuse the same DiagnosticsEngine.
llvm-svn: 197485
|
| |
|
|
|
|
| |
This was committed accidentally.
llvm-svn: 197389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
A better long-term strategy might be to not stat the header files at all
while reading the module map and instead read them only when the module
is being built (there is a corresponding FIXME in parseHeaderDecl()).
However, it seems non-trivial to get there and this would be a temporary
solution to unblock us.
Also changed the implementation to reuse the same DiagnosticsEngine as
otherwise warnings can't be enabled or disabled with command-line flags.
llvm-svn: 197388
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The warning for backslash and newline separated by whitespace was missed in
this code path.
backslash<whitespace><newline> is handled differently from compiler to compiler
so it's important to warn consistently where there's ambiguity.
Matches similar handling of block comments and non-comment lines.
llvm-svn: 197331
|
| |
|
|
|
|
| |
Raw lexers don't have a preprocessor so we need to null check.
llvm-svn: 197245
|
| |
|
|
|
|
| |
Fixes rdar://15644663.
llvm-svn: 197165
|
| |
|
|
|
|
|
|
|
|
|
| |
Includes might always pull in arbitrary header or data files outside of
modules. Among others, this includes builtin includes, which do not have
a module (story) yet.
Also cleanup implementation of ModuleMap::findModuleForHeader() to be
non-recursive.
llvm-svn: 197034
|
| |
|
|
|
|
| |
appease FileManager.
llvm-svn: 196865
|
| |
|
|
| |
llvm-svn: 196859
|
| |
|
|
|
|
| |
3-state enum.
llvm-svn: 196648
|
| |
|
|
| |
llvm-svn: 196584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to make the migration to modules easier, it seems to be helpful
to allow a 1:1 mapping between target names of a current build system
and the corresponding C++ modules. As such targets commonly contain
characters like "-". ":" and "/", allowing arbitrary quote-escaped
strings seems to be a straightforward option.
After several offline discussions, the precise mechanisms for C++
module names especially regarding submodules and import statements has
yet to be determined. Thus, this patch only enables string literals as
names inside the module map files which can be used by automatic module
import (through #include).
Also improve the error message on missing use-declarations.
llvm-svn: 196573
|
| |
|
|
|
|
|
|
| |
libclang.
Patch by Erik Verbruggen!
llvm-svn: 196487
|
| |
|
|
|
|
| |
re-org, and an update of the new PPCallbacks test (soon to be moved to clang from extra), rather the unittest.
llvm-svn: 196407
|
| |
|
|
|
|
|
|
| |
handle them (pr9537)"
It broke clang tests on some hosts with +Asserts. Seems "STDC" clashes.
llvm-svn: 196376
|
| |
|
|
|
|
|
| |
And refactor to have just one place in code that sets up the empty
pragma handlers.
llvm-svn: 196372
|
| |
|
|
|
|
|
|
|
|
|
| |
Before, there SourceManager would not return a FileEntry for a
SourceLocation of a macro expansion (if the header name itself is
defined in a macro). We'd then fallback to assume that the module
currently being built is the including module. However, in this case we
are actually interested in the spelling location of the filename loc in
order to derive the including module.
llvm-svn: 196311
|
| |
|
|
| |
llvm-svn: 196123
|
| |
|
|
|
|
| |
curlies.
llvm-svn: 195802
|
| |
|
|
|
|
|
| |
the duplicated documentation from .cpp files so that it's not processed by
Doxygen and hence doesn't generate duplicate output.
llvm-svn: 195799
|
| |
|
|
|
|
|
|
|
| |
module. Use the marker to diagnose cases where we try to transition between
submodules when not at the top level (most likely because a closing brace was
missing at the end of a header file, but is also possible if submodule headers
attempt to do something fundamentally non-modular, like our .def files).
llvm-svn: 195543
|
| |
|
|
| |
llvm-svn: 194897
|
| |
|
|
|
|
|
|
|
|
|
|
| |
representing the module import rather than making the module immediately
visible. This serves two goals:
* It avoids making declarations in the module visible prematurely, if we
walk past the #include during a tentative parse, for instance, and
* It gives a diagnostic (although, admittedly, not a very nice one) if
a header with a corresponding module is included anywhere other than
at the top level.
llvm-svn: 194782
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The preprocessor currently recognizes module declarations to load a
module based on seeing the 'import' keyword followed by an
identifier. This sequence is fairly unlikely in C (one would need a
type named 'import'), but is more common in Objective-C (where a
variable named 'import' can cause problems). Since import declarations
currently require a leading '@', recognize that in the preprocessor as
well. Fixes <rdar://problem/15084587>.
llvm-svn: 194225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'##'
After lexing a '##', we would look ahead and check to see if it was
followed by '__VA_ARGS__'. After doing so, we would then go ahead and
lex the token.
However we would fail in the case where the '##' was followed by a '#'
followed by an identifier because we would have lexed the '#' separately
from the identifier, bypassing our parameter validation logic.
Instead, lex the tokens coming after the '##' later.
This fixes PR17804.
llvm-svn: 194059
|
| |
|
|
|
|
| |
... in case someone decides to -I/usr/include <rdar://problem/15235948>.
llvm-svn: 193893
|
| |
|
|
|
|
|
|
|
|
|
|
| |
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
llvm-svn: 193314
|