maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Basic/TokenKinds.cpp

91 lines
3.3 KiB
C++
Raw Normal View History

Initial checkin of c-language parser llvm-svn: 38539
2006-06-18 13:43:12 +08:00
//===--- TokenKinds.cpp - Token Kinds Support -----------------------------===//
//
// The LLVM Compiler Infrastructure
//
Don't attribute in file headers anymore. See llvmdev for the discussion of this change. llvm-svn: 45410
2007-12-30 03:59:25 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Initial checkin of c-language parser llvm-svn: 38539
2006-06-18 13:43:12 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements the TokenKind enum and support functions.
//
//===----------------------------------------------------------------------===//
#include "clang/Basic/TokenKinds.h"
Modified current clients of Bitcode-Object serialization to use the new split-header file configuration (Serialize.h and Deserialize.h) now in place in the core LLVM repository. Removed unneeded SerializeTrait specializations for enums in TokenKinds.h llvm-svn: 43306
2007-10-25 03:06:02 +08:00
Initial checkin of c-language parser llvm-svn: 38539
2006-06-18 13:43:12 +08:00
#include <cassert>
Finally bite the bullet and make the major change: split the clang namespace out of the llvm namespace. This makes the clang namespace be a sibling of llvm instead of being a child. The good thing about this is that it makes many things unambiguous. The bad things is that many things in the llvm namespace (notably data structures like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport should be split out of llvm into their own namespace in the future, which will fix this issue. llvm-svn: 39659
2007-06-16 07:05:46 +08:00
using namespace clang;
Initial checkin of c-language parser llvm-svn: 38539
2006-06-18 13:43:12 +08:00
static const char * const TokNames[] = {
#define TOK(X) #X,
allow getTokenName to work for keywords. llvm-svn: 39243
2006-12-04 15:45:05 +08:00
#define KEYWORD(X,Y) #X,
Initial checkin of c-language parser llvm-svn: 38539
2006-06-18 13:43:12 +08:00
#include "clang/Basic/TokenKinds.def"
0
};
const char *tok::getTokenName(enum TokenKind Kind) {
assert(Kind < tok::NUM_TOKENS);
return TokNames[Kind];
}
Introduce code modification hints into the diagnostics system. When we know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). llvm-svn: 65570
2009-02-27 05:00:50 +08:00
Clean up and document code modification hints. llvm-svn: 65641
2009-02-28 01:53:17 +08:00
const char *tok::getTokenSimpleSpelling(enum TokenKind Kind) {
Introduce code modification hints into the diagnostics system. When we know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). llvm-svn: 65570
2009-02-27 05:00:50 +08:00
switch (Kind) {
case tok::l_square: return "[";
case tok::r_square: return "]";
case tok::l_paren: return "(";
case tok::r_paren: return ")";
case tok::l_brace: return "{";
case tok::r_brace: return "}";
case tok::period: return ".";
case tok::ellipsis: return "...";
case tok::amp: return "&";
case tok::ampamp: return "&&";
case tok::ampequal: return "&=";
case tok::star: return "*";
case tok::starequal: return "*=";
case tok::plus: return "+";
case tok::plusplus: return "++";
case tok::plusequal: return "+=";
case tok::minus: return "-";
case tok::arrow: return "->";
case tok::minusminus: return "--";
case tok::minusequal: return "-=";
case tok::tilde: return "~";
case tok::exclaim: return "!";
case tok::exclaimequal: return "!=";
case tok::slash: return "/";
case tok::slashequal: return "/=";
case tok::percent: return "%";
case tok::percentequal: return "%=";
case tok::less: return "<";
case tok::lessless: return "<<";
case tok::lessequal: return "<=";
case tok::lesslessequal: return "<<=";
case tok::greater: return ">";
case tok::greatergreater: return ">>";
case tok::greaterequal: return ">=";
case tok::greatergreaterequal: return ">>=";
case tok::caret: return "^";
case tok::caretequal: return "^=";
case tok::pipe: return "|";
case tok::pipepipe: return "||";
case tok::pipeequal: return "|=";
case tok::question: return "?";
case tok::colon: return ":";
case tok::semi: return ";";
case tok::equal: return "=";
case tok::equalequal: return "==";
case tok::comma: return ",";
case tok::hash: return "#";
case tok::hashhash: return "##";
case tok::hashat: return "#@";
case tok::periodstar: return ".*";
case tok::arrowstar: return "->*";
case tok::coloncolon: return "::";
case tok::at: return "@";
default: break;
}
return 0;
}