maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Frontend/system-header-line-directiv...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
929 B
C
Raw Normal View History

[Preprocessor] Correct internal token parsing of newline characters in CRLF Discovered due to a goofy git setup, the test system-headerline-directive.c (and a few others) failed because the token-consumption will consume only the '\r' in CRLF, making the preprocessor's printed value give the wrong line number when returning from an include. For example: (line 1):#include <noline.h>\r\n The "file exit" code causes the printer to try to print the 'returned to the main file' line. It looks up what the current line number is. However, since the current 'token' is the '\n' (since only the \r was consumed), it will give the line number as '1", not '2'. This results in a few failed tests, but more importantly, results in error messages being incorrect when compiling a previously preprocessed file. Differential Revision: https://reviews.llvm.org/D37079 llvm-svn: 311683
2017-08-25 02:36:07 +08:00
// RUN: %clang_cc1 %s -E -o - -I %S/Inputs -isystem %S/Inputs/SystemHeaderPrefix | FileCheck %s
#include <noline.h>
#include <line-directive-in-system.h>
#include "line-directive.h"
// This tests that the line numbers for the current file are correctly outputted
Remove .gitattributes, add comment to lineendings. llvm-svn: 311732
2017-08-25 07:25:05 +08:00
// for the include-file-completed test case. This file should be CRLF.
[Preprocessor] Correct internal token parsing of newline characters in CRLF Discovered due to a goofy git setup, the test system-headerline-directive.c (and a few others) failed because the token-consumption will consume only the '\r' in CRLF, making the preprocessor's printed value give the wrong line number when returning from an include. For example: (line 1):#include <noline.h>\r\n The "file exit" code causes the printer to try to print the 'returned to the main file' line. It looks up what the current line number is. However, since the current 'token' is the '\n' (since only the \r was consumed), it will give the line number as '1", not '2'. This results in a few failed tests, but more importantly, results in error messages being incorrect when compiling a previously preprocessed file. Differential Revision: https://reviews.llvm.org/D37079 llvm-svn: 311683
2017-08-25 02:36:07 +08:00
// CHECK: # 1 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
// CHECK: # 1 "{{.*}}noline.h" 1 3
// CHECK: foo();
// CHECK: # 3 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
// CHECK: # 1 "{{.*}}line-directive-in-system.h" 1 3
// The "3" below indicates that "foo.h" is considered a system header.
// CHECK: # 1 "foo.h" 3
// CHECK: foo();
// CHECK: # 4 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
// CHECK: # 1 "{{.*}}line-directive.h" 1
// CHECK: # 10 "foo.h"{{$}}
// CHECK: # 6 "{{.*}}system-header-line-directive-ms-lineendings.c" 2