fix PR3579: __LINE__ expands to the presumed location of the

*end* of a macro instantiation, not the start of it.  This is
really all about bug-for-bug compatibility with GCC, but not
doing this breaks the FreeBSD kernel.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64604 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2009-02-15 21:06:39 +00:00
Родитель c8fbd44eb0
Коммит 081927bbab
1 изменённых файлов: 11 добавлений и 1 удалений

Просмотреть файл

@ -464,7 +464,17 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// C99 6.10.8: "__LINE__: The presumed line number (within the current
// source file) of the current source line (an integer constant)". This can
// be affected by #line.
PresumedLoc PLoc = SourceMgr.getPresumedLoc(Tok.getLocation());
SourceLocation Loc = Tok.getLocation();
// One wrinkle here is that GCC expands __LINE__ to location of the *end* of
// a macro instantiation. This doesn't matter for object-like macros, but
// can matter for a function-like macro that expands to contain __LINE__.
// Skip down through instantiation points until we find a file loc for the
// end of the instantiation history.
while (!Loc.isFileID())
Loc = SourceMgr.getImmediateInstantiationRange(Loc).second;
PresumedLoc PLoc = SourceMgr.getPresumedLoc(Loc);
// __LINE__ expands to a simple numeric value. Add a space after it so that
// it will tokenize as a number (and not run into stuff after it in the temp