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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331244 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308008 91177308-0d34-0410-b5e6-96231b3b80d8
[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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258128 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236400 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236176 91177308-0d34-0410-b5e6-96231b3b80d8
Also flesh out missing tests, improve diagnostic QOI and fix a couple of corner
cases found in the process.
Fixes PR10606.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209276 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203974 91177308-0d34-0410-b5e6-96231b3b80d8
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">;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198189 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197972 91177308-0d34-0410-b5e6-96231b3b80d8
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. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187172 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186903 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178037 91177308-0d34-0410-b5e6-96231b3b80d8
The previous implementation missed the case where the elif condition was
evaluated from the context of an #ifdef that was false causing PR15539.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177345 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
> '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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164545 91177308-0d34-0410-b5e6-96231b3b80d8
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164484 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152098 91177308-0d34-0410-b5e6-96231b3b80d8
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149799 91177308-0d34-0410-b5e6-96231b3b80d8
This also adds a -Wc++98-compat-pedantic for warning on constructs which would
be diagnosed by -std=c++98 -pedantic (that is, it warns even on C++11 features
which we enable by default, with no warning, in C++98 mode).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142034 91177308-0d34-0410-b5e6-96231b3b80d8
Fangrui Song