| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
| |
The test case had a parse error that was causing the condition string to be misreported. We now have better fallback code for error cases.
llvm-svn: 351470
|
|
|
|
|
|
|
| |
This reverts commit r350891. Also add a test case that would return an
empty string with r350891.
llvm-svn: 351209
|
|
|
|
|
|
| |
diagnostic; NFC.
llvm-svn: 350912
|
|
|
|
|
|
| |
This adjusts the source range passed in to the preprocessor callbacks to only include the condition range itself, rather than all of the conditionally skipped tokens.
llvm-svn: 350891
|
|
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")
The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.
Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test
Differential Revision: https://reviews.llvm.org/D35172
llvm-svn: 308008
|
|
|
|
|
|
|
|
|
|
| |
parse all directive blocks if the condition uses undefined macros
This is useful for being able to parse the preprocessor directive blocks even if the header, that defined the macro that is checked, hasn't been included.
Differential Revision: https://reviews.llvm.org/D34263
llvm-svn: 305797
|
|
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: https://reviews.llvm.org/D24115
llvm-svn: 280870
|
|
|
|
|
|
| |
in a preprocessor constant expression.
llvm-svn: 266495
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[cpp.cond]p4:
Prior to evaluation, macro invocations in the list of preprocessing
tokens that will become the controlling constant expression are replaced
(except for those macro names modified by the 'defined' unary operator),
just as in normal text. If the token 'defined' is generated as a result
of this replacement process or use of the 'defined' unary operator does
not match one of the two specified forms prior to macro replacement, the
behavior is undefined.
This isn't an idle threat, consider this program:
#define FOO
#define BAR defined(FOO)
#if BAR
...
#else
...
#endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch. Emit a warning about this undefined behavior.
One problem is that this also applies to function-like macros. While the
example above can be written like
#if defined(FOO) && defined(BAR)
#defined HAVE_FOO 1
#else
#define HAVE_FOO 0
#endif
there is no easy way to rewrite a function-like macro like `#define FOO(x)
(defined __foo_##x && __foo_##x)`. Function-like macros like this are used in
practice, and compilers seem to not have differing behavior in that case. So
this a default-on warning only for object-like macros. For function-like
macros, it is an extension warning that only shows up with `-pedantic`.
(But it's undefined behavior in both cases.)
llvm-svn: 258128
|
|
|
|
| |
llvm-svn: 253119
|
|
|
|
| |
llvm-svn: 249259
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
| |
MacroDirective*, in order to preserve full information on module macro expansion.
llvm-svn: 236404
|
|
|
|
|
|
|
|
|
|
| |
Preprocessor::MacroDefinition -> MacroDefinition.
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
llvm-svn: 236400
|
|
|
|
| |
llvm-svn: 236390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
|
|
|
|
|
|
|
|
|
|
| |
literals based on underlying type of wchar_t.
Reviewed:
http://reviews.llvm.org/D7559
Patch by Rachel Craig; Test cases by Hubert Tong.
llvm-svn: 230333
|
|
|
|
| |
llvm-svn: 221576
|
|
|
|
| |
llvm-svn: 220572
|
|
|
|
| |
llvm-svn: 219637
|
|
|
|
|
|
| |
feedback from Richard Smith. Amends r213657.
llvm-svn: 213865
|
|
|
|
|
|
| |
This will be used to improve other diagnostics.
llvm-svn: 213657
|
|
|
|
|
|
|
|
|
| |
Also flesh out missing tests, improve diagnostic QOI and fix a couple of corner
cases found in the process.
Fixes PR10606.
llvm-svn: 209276
|
|
|
|
| |
llvm-svn: 209083
|
|
|
|
|
|
|
|
| |
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long. So C99 conformance requires not conforming to C99. :)
llvm-svn: 187172
|
|
|
|
|
|
|
|
| |
Switch some warnings over to errors which should never have been warnings
in the first place. (Also, a minor fix to the preprocessor rules for
integer literals while I'm here.)
llvm-svn: 186903
|
|
|
|
| |
llvm-svn: 186707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroDirective's subclasses.
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
|
|
|
|
|
|
|
| |
The previous implementation missed the case where the elif condition was
evaluated from the context of an #ifdef that was false causing PR15539.
llvm-svn: 177345
|
|
|
|
|
|
|
|
| |
available the
full information about the macro (e.g if it was imported and where).
llvm-svn: 175978
|
|
|
|
| |
llvm-svn: 174075
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
| |
a MacroInfo object if the identifier was a macro name.
llvm-svn: 169665
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169237
|
|
|
|
|
|
|
|
|
| |
> 'long long' is an extension when C99 mode is not enabled
to
> 'long long' is a C++11 extension
while compiling in C++98 mode.
llvm-svn: 164545
|
|
|
|
|
|
|
| |
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
llvm-svn: 164484
|
|
|
|
| |
llvm-svn: 164279
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
| |
user-defined-floating-literal. Support for raw forms of these literals
to follow.
llvm-svn: 152302
|
|
|
|
|
|
|
|
|
|
| |
grammar requires a string-literal and not a user-defined-string-literal. The
two constructs are still represented by the same TokenKind, in order to prevent
a combinatorial explosion of different kinds of token. A flag on Token tracks
whether a ud-suffix is present, in order to prevent clients from needing to look
at the token's spelling.
llvm-svn: 152098
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|