2008-12-02 12:01:29 +01:00
|
|
|
// Copyright (c) 2008 Roberto Raggi <roberto.raggi@gmail.com>
|
|
|
|
|
//
|
|
|
|
|
// Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
|
// of this software and associated documentation files (the "Software"), to deal
|
|
|
|
|
// in the Software without restriction, including without limitation the rights
|
|
|
|
|
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
|
// copies of the Software, and to permit persons to whom the Software is
|
|
|
|
|
// furnished to do so, subject to the following conditions:
|
|
|
|
|
//
|
|
|
|
|
// The above copyright notice and this permission notice shall be included in
|
|
|
|
|
// all copies or substantial portions of the Software.
|
|
|
|
|
//
|
|
|
|
|
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
|
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
|
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
|
// THE SOFTWARE.
|
|
|
|
|
|
|
|
|
|
#ifndef CPLUSPLUS_TOKEN_H
|
|
|
|
|
#define CPLUSPLUS_TOKEN_H
|
|
|
|
|
|
|
|
|
|
#include "CPlusPlusForwardDeclarations.h"
|
2009-10-20 11:21:25 +02:00
|
|
|
|
|
|
|
|
namespace CPlusPlus {
|
2008-12-02 12:01:29 +01:00
|
|
|
|
|
|
|
|
enum Kind {
|
|
|
|
|
T_EOF_SYMBOL = 0,
|
|
|
|
|
T_ERROR,
|
|
|
|
|
|
2009-09-29 11:34:11 +02:00
|
|
|
T_CPP_COMMENT,
|
|
|
|
|
T_CPP_DOXY_COMMENT,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_COMMENT,
|
2009-02-20 11:52:27 +01:00
|
|
|
T_DOXY_COMMENT,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_IDENTIFIER,
|
|
|
|
|
|
|
|
|
|
T_FIRST_LITERAL,
|
2009-07-10 15:44:47 +02:00
|
|
|
T_NUMERIC_LITERAL = T_FIRST_LITERAL,
|
2012-06-05 17:24:53 +02:00
|
|
|
T_FIRST_CHAR_LITERAL,
|
|
|
|
|
T_CHAR_LITERAL = T_FIRST_CHAR_LITERAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_WIDE_CHAR_LITERAL,
|
2012-06-06 13:41:22 +02:00
|
|
|
T_UTF16_CHAR_LITERAL,
|
|
|
|
|
T_UTF32_CHAR_LITERAL,
|
|
|
|
|
T_LAST_CHAR_LITERAL = T_UTF32_CHAR_LITERAL,
|
2012-06-05 17:24:53 +02:00
|
|
|
T_FIRST_STRING_LITERAL,
|
|
|
|
|
T_STRING_LITERAL = T_FIRST_STRING_LITERAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_WIDE_STRING_LITERAL,
|
2012-06-06 13:41:22 +02:00
|
|
|
T_UTF8_STRING_LITERAL,
|
|
|
|
|
T_UTF16_STRING_LITERAL,
|
|
|
|
|
T_UTF32_STRING_LITERAL,
|
2012-08-16 21:17:41 +02:00
|
|
|
T_RAW_STRING_LITERAL,
|
|
|
|
|
T_RAW_WIDE_STRING_LITERAL,
|
|
|
|
|
T_RAW_UTF8_STRING_LITERAL,
|
|
|
|
|
T_RAW_UTF16_STRING_LITERAL,
|
|
|
|
|
T_RAW_UTF32_STRING_LITERAL,
|
2010-02-15 12:23:48 +01:00
|
|
|
T_AT_STRING_LITERAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_ANGLE_STRING_LITERAL,
|
2012-06-05 17:24:53 +02:00
|
|
|
T_LAST_STRING_LITERAL = T_ANGLE_STRING_LITERAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_LAST_LITERAL = T_ANGLE_STRING_LITERAL,
|
|
|
|
|
|
|
|
|
|
T_FIRST_OPERATOR,
|
|
|
|
|
T_AMPER = T_FIRST_OPERATOR,
|
|
|
|
|
T_AMPER_AMPER,
|
|
|
|
|
T_AMPER_EQUAL,
|
|
|
|
|
T_ARROW,
|
|
|
|
|
T_ARROW_STAR,
|
|
|
|
|
T_CARET,
|
|
|
|
|
T_CARET_EQUAL,
|
|
|
|
|
T_COLON,
|
|
|
|
|
T_COLON_COLON,
|
|
|
|
|
T_COMMA,
|
|
|
|
|
T_SLASH,
|
|
|
|
|
T_SLASH_EQUAL,
|
|
|
|
|
T_DOT,
|
|
|
|
|
T_DOT_DOT_DOT,
|
|
|
|
|
T_DOT_STAR,
|
|
|
|
|
T_EQUAL,
|
|
|
|
|
T_EQUAL_EQUAL,
|
|
|
|
|
T_EXCLAIM,
|
|
|
|
|
T_EXCLAIM_EQUAL,
|
|
|
|
|
T_GREATER,
|
|
|
|
|
T_GREATER_EQUAL,
|
|
|
|
|
T_GREATER_GREATER,
|
|
|
|
|
T_GREATER_GREATER_EQUAL,
|
|
|
|
|
T_LBRACE,
|
|
|
|
|
T_LBRACKET,
|
|
|
|
|
T_LESS,
|
|
|
|
|
T_LESS_EQUAL,
|
|
|
|
|
T_LESS_LESS,
|
|
|
|
|
T_LESS_LESS_EQUAL,
|
|
|
|
|
T_LPAREN,
|
|
|
|
|
T_MINUS,
|
|
|
|
|
T_MINUS_EQUAL,
|
|
|
|
|
T_MINUS_MINUS,
|
|
|
|
|
T_PERCENT,
|
|
|
|
|
T_PERCENT_EQUAL,
|
|
|
|
|
T_PIPE,
|
|
|
|
|
T_PIPE_EQUAL,
|
|
|
|
|
T_PIPE_PIPE,
|
|
|
|
|
T_PLUS,
|
|
|
|
|
T_PLUS_EQUAL,
|
|
|
|
|
T_PLUS_PLUS,
|
|
|
|
|
T_POUND,
|
|
|
|
|
T_POUND_POUND,
|
|
|
|
|
T_QUESTION,
|
|
|
|
|
T_RBRACE,
|
|
|
|
|
T_RBRACKET,
|
|
|
|
|
T_RPAREN,
|
|
|
|
|
T_SEMICOLON,
|
|
|
|
|
T_STAR,
|
|
|
|
|
T_STAR_EQUAL,
|
|
|
|
|
T_TILDE,
|
|
|
|
|
T_TILDE_EQUAL,
|
|
|
|
|
T_LAST_OPERATOR = T_TILDE_EQUAL,
|
|
|
|
|
|
|
|
|
|
T_FIRST_KEYWORD,
|
2012-09-17 13:34:36 +02:00
|
|
|
T_ALIGNAS = T_FIRST_KEYWORD,
|
|
|
|
|
T_ALIGNOF,
|
|
|
|
|
T_ASM,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_AUTO,
|
|
|
|
|
T_BOOL,
|
|
|
|
|
T_BREAK,
|
|
|
|
|
T_CASE,
|
|
|
|
|
T_CATCH,
|
|
|
|
|
T_CHAR,
|
2012-06-06 13:41:22 +02:00
|
|
|
T_CHAR16_T,
|
|
|
|
|
T_CHAR32_T,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_CLASS,
|
|
|
|
|
T_CONST,
|
|
|
|
|
T_CONST_CAST,
|
2011-11-18 11:40:23 +01:00
|
|
|
T_CONSTEXPR,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_CONTINUE,
|
2012-02-10 14:41:58 +01:00
|
|
|
T_DECLTYPE,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_DEFAULT,
|
|
|
|
|
T_DELETE,
|
|
|
|
|
T_DO,
|
|
|
|
|
T_DOUBLE,
|
|
|
|
|
T_DYNAMIC_CAST,
|
|
|
|
|
T_ELSE,
|
|
|
|
|
T_ENUM,
|
|
|
|
|
T_EXPLICIT,
|
|
|
|
|
T_EXPORT,
|
|
|
|
|
T_EXTERN,
|
|
|
|
|
T_FALSE,
|
|
|
|
|
T_FLOAT,
|
|
|
|
|
T_FOR,
|
|
|
|
|
T_FRIEND,
|
|
|
|
|
T_GOTO,
|
|
|
|
|
T_IF,
|
|
|
|
|
T_INLINE,
|
|
|
|
|
T_INT,
|
|
|
|
|
T_LONG,
|
|
|
|
|
T_MUTABLE,
|
|
|
|
|
T_NAMESPACE,
|
|
|
|
|
T_NEW,
|
2012-02-02 11:40:01 +01:00
|
|
|
T_NOEXCEPT,
|
2011-11-18 13:33:26 +01:00
|
|
|
T_NULLPTR,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_OPERATOR,
|
|
|
|
|
T_PRIVATE,
|
|
|
|
|
T_PROTECTED,
|
|
|
|
|
T_PUBLIC,
|
|
|
|
|
T_REGISTER,
|
|
|
|
|
T_REINTERPRET_CAST,
|
|
|
|
|
T_RETURN,
|
|
|
|
|
T_SHORT,
|
|
|
|
|
T_SIGNED,
|
|
|
|
|
T_SIZEOF,
|
|
|
|
|
T_STATIC,
|
2012-02-02 13:39:24 +01:00
|
|
|
T_STATIC_ASSERT,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_STATIC_CAST,
|
|
|
|
|
T_STRUCT,
|
|
|
|
|
T_SWITCH,
|
|
|
|
|
T_TEMPLATE,
|
|
|
|
|
T_THIS,
|
2013-11-24 18:25:32 +02:00
|
|
|
T_THREAD_LOCAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_THROW,
|
|
|
|
|
T_TRUE,
|
|
|
|
|
T_TRY,
|
|
|
|
|
T_TYPEDEF,
|
|
|
|
|
T_TYPEID,
|
|
|
|
|
T_TYPENAME,
|
|
|
|
|
T_UNION,
|
|
|
|
|
T_UNSIGNED,
|
|
|
|
|
T_USING,
|
|
|
|
|
T_VIRTUAL,
|
|
|
|
|
T_VOID,
|
|
|
|
|
T_VOLATILE,
|
|
|
|
|
T_WCHAR_T,
|
|
|
|
|
T_WHILE,
|
|
|
|
|
|
|
|
|
|
T___ATTRIBUTE__,
|
2013-11-24 18:25:32 +02:00
|
|
|
T___THREAD,
|
2008-12-02 12:01:29 +01:00
|
|
|
T___TYPEOF__,
|
|
|
|
|
|
2010-02-15 12:23:48 +01:00
|
|
|
// obj c++ @ keywords
|
|
|
|
|
T_FIRST_OBJC_AT_KEYWORD,
|
|
|
|
|
|
|
|
|
|
T_AT_CATCH = T_FIRST_OBJC_AT_KEYWORD,
|
|
|
|
|
T_AT_CLASS,
|
|
|
|
|
T_AT_COMPATIBILITY_ALIAS,
|
|
|
|
|
T_AT_DEFS,
|
|
|
|
|
T_AT_DYNAMIC,
|
|
|
|
|
T_AT_ENCODE,
|
|
|
|
|
T_AT_END,
|
|
|
|
|
T_AT_FINALLY,
|
|
|
|
|
T_AT_IMPLEMENTATION,
|
|
|
|
|
T_AT_INTERFACE,
|
|
|
|
|
T_AT_NOT_KEYWORD,
|
|
|
|
|
T_AT_OPTIONAL,
|
|
|
|
|
T_AT_PACKAGE,
|
|
|
|
|
T_AT_PRIVATE,
|
|
|
|
|
T_AT_PROPERTY,
|
|
|
|
|
T_AT_PROTECTED,
|
|
|
|
|
T_AT_PROTOCOL,
|
|
|
|
|
T_AT_PUBLIC,
|
|
|
|
|
T_AT_REQUIRED,
|
|
|
|
|
T_AT_SELECTOR,
|
|
|
|
|
T_AT_SYNCHRONIZED,
|
|
|
|
|
T_AT_SYNTHESIZE,
|
|
|
|
|
T_AT_THROW,
|
|
|
|
|
T_AT_TRY,
|
|
|
|
|
|
|
|
|
|
T_LAST_OBJC_AT_KEYWORD = T_AT_TRY,
|
2009-01-12 14:55:33 +01:00
|
|
|
|
2009-07-13 12:05:29 +02:00
|
|
|
T_FIRST_QT_KEYWORD,
|
2008-12-02 12:01:29 +01:00
|
|
|
|
|
|
|
|
// Qt keywords
|
2012-06-28 10:55:51 +02:00
|
|
|
T_EMIT = T_FIRST_QT_KEYWORD,
|
|
|
|
|
T_SIGNAL,
|
2008-12-02 12:01:29 +01:00
|
|
|
T_SLOT,
|
2009-03-25 11:50:17 +01:00
|
|
|
T_Q_SIGNAL,
|
|
|
|
|
T_Q_SLOT,
|
2009-07-03 09:11:52 +02:00
|
|
|
T_Q_SIGNALS,
|
|
|
|
|
T_Q_SLOTS,
|
|
|
|
|
T_Q_FOREACH,
|
2009-11-30 16:30:21 +01:00
|
|
|
T_Q_D,
|
|
|
|
|
T_Q_Q,
|
2010-01-19 15:26:08 +10:00
|
|
|
T_Q_INVOKABLE,
|
|
|
|
|
T_Q_PROPERTY,
|
2010-12-08 15:08:03 +01:00
|
|
|
T_Q_PRIVATE_PROPERTY,
|
2010-03-16 17:29:40 +01:00
|
|
|
T_Q_INTERFACES,
|
2012-06-28 10:55:51 +02:00
|
|
|
T_Q_EMIT,
|
2010-01-19 15:26:08 +10:00
|
|
|
T_Q_ENUMS,
|
|
|
|
|
T_Q_FLAGS,
|
2010-03-17 14:35:48 +01:00
|
|
|
T_Q_PRIVATE_SLOT,
|
|
|
|
|
T_Q_DECLARE_INTERFACE,
|
|
|
|
|
T_Q_OBJECT,
|
|
|
|
|
T_Q_GADGET,
|
|
|
|
|
T_LAST_KEYWORD = T_Q_GADGET,
|
2010-02-04 12:03:34 +01:00
|
|
|
|
2008-12-10 13:27:59 +01:00
|
|
|
// aliases
|
|
|
|
|
T_OR = T_PIPE_PIPE,
|
|
|
|
|
T_AND = T_AMPER_AMPER,
|
|
|
|
|
T_NOT = T_EXCLAIM,
|
|
|
|
|
T_XOR = T_CARET,
|
|
|
|
|
T_BITOR = T_PIPE,
|
|
|
|
|
T_COMPL = T_TILDE,
|
|
|
|
|
T_OR_EQ = T_PIPE_EQUAL,
|
|
|
|
|
T_AND_EQ = T_AMPER_EQUAL,
|
|
|
|
|
T_BITAND = T_AMPER,
|
|
|
|
|
T_NOT_EQ = T_EXCLAIM_EQUAL,
|
|
|
|
|
T_XOR_EQ = T_CARET_EQUAL,
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
T___ASM = T_ASM,
|
|
|
|
|
T___ASM__ = T_ASM,
|
|
|
|
|
|
|
|
|
|
T_TYPEOF = T___TYPEOF__,
|
|
|
|
|
T___TYPEOF = T___TYPEOF__,
|
|
|
|
|
|
2012-02-10 14:41:58 +01:00
|
|
|
T___DECLTYPE = T_DECLTYPE,
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
T___INLINE = T_INLINE,
|
|
|
|
|
T___INLINE__ = T_INLINE,
|
|
|
|
|
|
|
|
|
|
T___CONST = T_CONST,
|
|
|
|
|
T___CONST__ = T_CONST,
|
|
|
|
|
|
|
|
|
|
T___VOLATILE = T_VOLATILE,
|
|
|
|
|
T___VOLATILE__ = T_VOLATILE,
|
|
|
|
|
|
|
|
|
|
T___ATTRIBUTE = T___ATTRIBUTE__
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class CPLUSPLUS_EXPORT Token
|
|
|
|
|
{
|
|
|
|
|
public:
|
2014-02-25 13:44:11 -03:00
|
|
|
Token() : flags(0), byteOffset(0), utf16charOffset(0), ptr(0) {}
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2009-07-27 21:47:03 +02:00
|
|
|
inline bool is(unsigned k) const { return f.kind == k; }
|
|
|
|
|
inline bool isNot(unsigned k) const { return f.kind != k; }
|
2008-12-02 12:01:29 +01:00
|
|
|
const char *spell() const;
|
|
|
|
|
void reset();
|
|
|
|
|
|
2009-11-13 16:59:09 +01:00
|
|
|
inline unsigned kind() const { return f.kind; }
|
|
|
|
|
inline bool newline() const { return f.newline; }
|
|
|
|
|
inline bool whitespace() const { return f.whitespace; }
|
|
|
|
|
inline bool joined() const { return f.joined; }
|
|
|
|
|
inline bool expanded() const { return f.expanded; }
|
|
|
|
|
inline bool generated() const { return f.generated; }
|
|
|
|
|
|
2014-02-25 13:44:11 -03:00
|
|
|
inline unsigned bytes() const { return f.bytes; }
|
|
|
|
|
inline unsigned bytesBegin() const { return byteOffset; }
|
|
|
|
|
inline unsigned bytesEnd() const { return byteOffset + f.bytes; }
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2014-02-25 13:44:11 -03:00
|
|
|
inline unsigned utf16chars() const { return f.utf16chars; }
|
|
|
|
|
inline unsigned utf16charsBegin() const { return utf16charOffset; }
|
|
|
|
|
inline unsigned utf16charsEnd() const { return utf16charOffset + f.utf16chars; }
|
2008-12-02 12:01:29 +01:00
|
|
|
|
|
|
|
|
inline bool isLiteral() const
|
2009-07-27 21:47:03 +02:00
|
|
|
{ return f.kind >= T_FIRST_LITERAL && f.kind <= T_LAST_LITERAL; }
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2012-06-05 17:24:53 +02:00
|
|
|
inline bool isCharLiteral() const
|
|
|
|
|
{ return f.kind >= T_FIRST_CHAR_LITERAL && f.kind <= T_LAST_CHAR_LITERAL; }
|
|
|
|
|
|
|
|
|
|
inline bool isStringLiteral() const
|
|
|
|
|
{ return f.kind >= T_FIRST_STRING_LITERAL && f.kind <= T_LAST_STRING_LITERAL; }
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
inline bool isOperator() const
|
2009-07-27 21:47:03 +02:00
|
|
|
{ return f.kind >= T_FIRST_OPERATOR && f.kind <= T_LAST_OPERATOR; }
|
2008-12-02 12:01:29 +01:00
|
|
|
|
|
|
|
|
inline bool isKeyword() const
|
2009-07-27 21:47:03 +02:00
|
|
|
{ return f.kind >= T_FIRST_KEYWORD && f.kind < T_FIRST_QT_KEYWORD; }
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2009-02-20 11:52:27 +01:00
|
|
|
inline bool isComment() const
|
2009-09-29 11:34:11 +02:00
|
|
|
{ return f.kind == T_COMMENT || f.kind == T_DOXY_COMMENT ||
|
|
|
|
|
f.kind == T_CPP_COMMENT || f.kind == T_CPP_DOXY_COMMENT; }
|
2009-02-20 11:52:27 +01:00
|
|
|
|
2010-02-15 12:23:48 +01:00
|
|
|
inline bool isObjCAtKeyword() const
|
|
|
|
|
{ return f.kind >= T_FIRST_OBJC_AT_KEYWORD && f.kind <= T_LAST_OBJC_AT_KEYWORD; }
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
static const char *name(int kind);
|
|
|
|
|
|
|
|
|
|
public:
|
2009-07-27 21:47:03 +02:00
|
|
|
struct Flags {
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// The token kind.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned kind : 8;
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// The token starts a new line.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned newline : 1;
|
|
|
|
|
// The token is preceeded by whitespace(s).
|
|
|
|
|
unsigned whitespace : 1;
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// The token is joined with the previous one.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned joined : 1;
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// The token originates from a macro expansion.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned expanded : 1;
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// The token originates from a macro expansion and does not correspond to an
|
|
|
|
|
// argument that went through substitution. Notice the example:
|
|
|
|
|
//
|
|
|
|
|
// #define FOO(a, b) a + b;
|
|
|
|
|
// FOO(1, 2)
|
|
|
|
|
//
|
|
|
|
|
// After preprocessing we would expect the following tokens: 1 + 2;
|
|
|
|
|
// Tokens '1', '+', '2', and ';' are all expanded. However only tokens '+' and ';'
|
|
|
|
|
// are generated.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned generated : 1;
|
C++: Core changes in preprocessing
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
2012-06-20 15:22:02 +02:00
|
|
|
// Unused...
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned pad : 3;
|
2014-02-25 13:44:11 -03:00
|
|
|
// The token length in bytes and UTF16 chars.
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned bytes : 16;
|
2014-02-25 13:44:11 -03:00
|
|
|
unsigned utf16chars : 16;
|
2009-07-27 21:47:03 +02:00
|
|
|
};
|
2008-12-02 12:01:29 +01:00
|
|
|
union {
|
2014-02-25 13:44:11 -03:00
|
|
|
unsigned long flags;
|
2009-07-27 21:47:03 +02:00
|
|
|
Flags f;
|
2008-12-02 12:01:29 +01:00
|
|
|
};
|
|
|
|
|
|
2013-12-13 18:41:15 +01:00
|
|
|
unsigned byteOffset;
|
2014-02-25 13:44:11 -03:00
|
|
|
unsigned utf16charOffset;
|
2008-12-02 12:01:29 +01:00
|
|
|
|
|
|
|
|
union {
|
|
|
|
|
void *ptr;
|
2009-12-01 11:33:13 +01:00
|
|
|
const Literal *literal;
|
|
|
|
|
const NumericLiteral *number;
|
|
|
|
|
const StringLiteral *string;
|
|
|
|
|
const Identifier *identifier;
|
2008-12-02 12:01:29 +01:00
|
|
|
unsigned close_brace;
|
|
|
|
|
unsigned lineno;
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2013-10-06 02:41:22 +02:00
|
|
|
struct LanguageFeatures
|
|
|
|
|
{
|
|
|
|
|
LanguageFeatures() : flags(0) {}
|
|
|
|
|
|
|
|
|
|
union {
|
|
|
|
|
unsigned int flags;
|
|
|
|
|
struct {
|
|
|
|
|
unsigned int qtEnabled : 1; // If Qt is used.
|
|
|
|
|
unsigned int qtMocRunEnabled : 1;
|
|
|
|
|
unsigned int qtKeywordsEnabled : 1; // If Qt is used but QT_NO_KEYWORDS defined
|
|
|
|
|
unsigned int cxx11Enabled : 1;
|
|
|
|
|
unsigned int objCEnabled : 1;
|
2014-05-05 22:56:15 +08:00
|
|
|
unsigned int c99Enabled : 1;
|
2013-10-06 02:41:22 +02:00
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2011-02-04 09:52:39 +01:00
|
|
|
} // namespace CPlusPlus
|
2009-10-20 11:21:25 +02:00
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
#endif // CPLUSPLUS_TOKEN_H
|