Files
qt-creator/src/libs/3rdparty/cplusplus/Token.h

378 lines
8.7 KiB
C
Raw Normal View History

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"
namespace CPlusPlus {
2008-12-02 12:01:29 +01:00
enum Kind {
T_EOF_SYMBOL = 0,
T_ERROR,
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,
T_NUMERIC_LITERAL = T_FIRST_LITERAL,
T_FIRST_CHAR_LITERAL,
T_CHAR_LITERAL = T_FIRST_CHAR_LITERAL,
2008-12-02 12:01:29 +01:00
T_WIDE_CHAR_LITERAL,
T_UTF16_CHAR_LITERAL,
T_UTF32_CHAR_LITERAL,
T_LAST_CHAR_LITERAL = T_UTF32_CHAR_LITERAL,
T_FIRST_STRING_LITERAL,
T_STRING_LITERAL = T_FIRST_STRING_LITERAL,
2008-12-02 12:01:29 +01:00
T_WIDE_STRING_LITERAL,
T_UTF8_STRING_LITERAL,
T_UTF16_STRING_LITERAL,
T_UTF32_STRING_LITERAL,
T_RAW_STRING_LITERAL,
T_RAW_WIDE_STRING_LITERAL,
T_RAW_UTF8_STRING_LITERAL,
T_RAW_UTF16_STRING_LITERAL,
T_RAW_UTF32_STRING_LITERAL,
T_AT_STRING_LITERAL,
2008-12-02 12:01:29 +01:00
T_ANGLE_STRING_LITERAL,
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,
T_ASM = T_FIRST_KEYWORD,
T_AUTO,
T_BOOL,
T_BREAK,
T_CASE,
T_CATCH,
T_CHAR,
T_CHAR16_T,
T_CHAR32_T,
2008-12-02 12:01:29 +01:00
T_CLASS,
T_CONST,
T_CONST_CAST,
T_CONSTEXPR,
2008-12-02 12:01:29 +01:00
T_CONTINUE,
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,
T_NOEXCEPT,
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,
T_STATIC_ASSERT,
2008-12-02 12:01:29 +01:00
T_STATIC_CAST,
T_STRUCT,
T_SWITCH,
T_TEMPLATE,
T_THIS,
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__,
T___TYPEOF__,
// 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
T_FIRST_QT_KEYWORD,
2008-12-02 12:01:29 +01:00
// Qt keywords
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,
T_Q_SIGNALS,
T_Q_SLOTS,
T_Q_FOREACH,
T_Q_D,
T_Q_Q,
T_Q_INVOKABLE,
T_Q_PROPERTY,
T_Q_PRIVATE_PROPERTY,
2010-03-16 17:29:40 +01:00
T_Q_INTERFACES,
T_Q_EMIT,
T_Q_ENUMS,
T_Q_FLAGS,
T_Q_PRIVATE_SLOT,
T_Q_DECLARE_INTERFACE,
T_Q_OBJECT,
T_Q_GADGET,
T_LAST_KEYWORD = T_Q_GADGET,
// 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__,
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:
Token() : flags(0), offset(0), ptr(0) {}
2008-12-02 12:01:29 +01: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; }
inline unsigned length() const { return f.length; }
2008-12-02 12:01:29 +01:00
inline unsigned begin() const
{ return offset; }
inline unsigned end() const
{ return offset + f.length; }
2008-12-02 12:01:29 +01:00
inline bool isLiteral() const
{ return f.kind >= T_FIRST_LITERAL && f.kind <= T_LAST_LITERAL; }
2008-12-02 12:01:29 +01: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
{ return f.kind >= T_FIRST_OPERATOR && f.kind <= T_LAST_OPERATOR; }
2008-12-02 12:01:29 +01:00
inline bool isKeyword() const
{ 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
{ 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
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:
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.
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.
unsigned newline : 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 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.
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.
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.
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...
unsigned pad : 3;
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 lenght.
unsigned length : 16;
};
2008-12-02 12:01:29 +01:00
union {
unsigned flags;
Flags f;
2008-12-02 12:01:29 +01:00
};
unsigned offset;
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;
};
};
} // namespace CPlusPlus
2008-12-02 12:01:29 +01:00
#endif // CPLUSPLUS_TOKEN_H