[llvm-bugs] [Bug 51616] New: Bad newlines in -E -P output after <https://reviews.llvm.org/D106924> "[Preprocessor] -E -P: Ensure newline after 8 skipped lines."

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 25 01:30:17 PDT 2021


            Bug ID: 51616
           Summary: Bad newlines in -E -P output after
                    <https://reviews.llvm.org/D106924> "[Preprocessor] -E
                    -P: Ensure newline after 8 skipped lines."
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: stephan.bergmann.secondary at googlemail.com
                CC: llvm-bugs at lists.llvm.org, llvm at meinersbur.de,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

"[Preprocessor] -E -P: Ensure newline after 8 skipped lines" on the main branch
towards LLVM 14 caused various issues regarding newlines in the `clang -E -P`

(1)  The output now starts with a spurious empty line,

> $ cat test1.c
> foo
> $ clang -E -P test1.c
> foo

where before that commit it did not,

> $ clang -E -P test1.c
> foo

That is caused by

> # 1 "<command line>" 1

(from clang::InitializePreprocessor, clang/lib/Frontend/InitPreprocessor.cpp)

> #0  (anonymous namespace)::PrintPPOutputPPCallbacks::MoveToLine (this=0x308a50, LineNo=342, RequireStartOfLine=false) at clang/lib/Frontend/PrintPreprocessedOutput.cpp:265
> #1  0x00007fffeda82c70 in (anonymous namespace)::PrintPPOutputPPCallbacks::MoveToLine (this=0x308a50, Loc=..., RequireStartOfLine=false) at clang/lib/Frontend/PrintPreprocessedOutput.cpp:203
> #2  0x00007fffeda831a5 in (anonymous namespace)::PrintPPOutputPPCallbacks::FileChanged (this=0x308a50, Loc=..., Reason=clang::PPCallbacks::EnterFile, NewFileType=clang::SrcMgr::C_User, PrevFID=...) at clang/lib/Frontend/PrintPreprocessedOutput.cpp:340
> #3  0x00007fffe55f6579 in clang::Preprocessor::HandleDigitDirective (this=0x3030d0, DigitTok=...) at clang/lib/Lex/PPDirectives.cpp:1475
> #4  0x00007fffe55f4e9d in clang::Preprocessor::HandleDirective (this=0x3030d0, Result=...) at clang/lib/Lex/PPDirectives.cpp:1073
> #5  0x00007fffe55a3f87 in clang::Lexer::LexTokenInternal (this=0x30ea90, Result=..., TokAtPhysicalStartOfLine=true) at clang/lib/Lex/Lexer.cpp:4065
> #6  0x00007fffe55a14fa in clang::Lexer::Lex (this=0x30ea90, Result=...) at clang/lib/Lex/Lexer.cpp:3280
> #7  0x00007fffe564a90c in clang::Preprocessor::Lex (this=0x3030d0, Result=...) at clang/lib/Lex/Preprocessor.cpp:900
> #8  0x00007fffeda856c5 in clang::DoPrintPreprocessedInput (PP=..., OS=0x3094b0, Opts=...) at clang/lib/Frontend/PrintPreprocessedOutput.cpp:992
> #9  0x00007fffeda45eca in clang::PrintPreprocessedAction::ExecuteAction (this=0x2ef950) at clang/lib/Frontend/FrontendActions.cpp:882
> #10 0x00007fffeda355d1 in clang::FrontendAction::Execute (this=0x2ef950) at clang/lib/Frontend/FrontendAction.cpp:951
> #11 0x00007fffed962070 in clang::CompilerInstance::ExecuteAction (this=0x2f5150, Act=...) at clang/lib/Frontend/CompilerInstance.cpp:974
> #12 0x00007ffff27fdd0c in clang::ExecuteCompilerInvocation (Clang=0x2f5150) at clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278
> #13 0x000000000023cc65 in cc1_main (Argv=..., Argv0=..., MainAddr=0x230646 <GetExecutablePath[abi:cxx11](char const*, bool)>) at clang/tools/driver/cc1_main.cpp:246
> #14 0x0000000000231d71 in ExecuteCC1Tool (ArgV=...) at clang/tools/driver/driver.cpp:338
> #15 0x00007fffed3f1445 in operator() (__closure=0x7fffffffba80) at clang/lib/Driver/Job.cpp:405
> #16 0x00007fffed3f199a in llvm::function_ref<void()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::string*, bool*) const::<lambda()> >(intptr_t) (callable=140737488337536) at llvm/include/llvm/ADT/STLExtras.h:177
> #17 0x00007fffe9d9a5ee in llvm::function_ref<void ()>::operator()() const (this=0x7fffffffb5b0) at llvm/include/llvm/ADT/STLExtras.h:200
> #18 0x00007fffe9dac92b in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (this=0x7fffffffb640, Fn=...) at llvm/lib/Support/CrashRecoveryContext.cpp:425
> #19 0x00007fffed3f1621 in clang::driver::CC1Command::Execute (this=0x2f5d20, Redirects=..., ErrMsg=0x7fffffffbb10, ExecutionFailed=0x7fffffffbb0f) at clang/lib/Driver/Job.cpp:405
> #20 0x00007fffed39258a in clang::driver::Compilation::ExecuteCommand (this=0x287350, C=..., FailingCommand=@0x7fffffffbc18: 0x0) at clang/lib/Driver/Compilation.cpp:196
> #21 0x00007fffed3928af in clang::driver::Compilation::ExecuteJobs (this=0x287350, Jobs=..., FailingCommands=...) at clang/lib/Driver/Compilation.cpp:249
> #22 0x00007fffed3a7758 in clang::driver::Driver::ExecuteCompilation (this=0x7fffffffbeb0, C=..., FailingCommands=...) at clang/lib/Driver/Driver.cpp:1553
> #23 0x0000000000232c48 in main (Argc=5, Argv=0x7fffffffd588) at clang/tools/driver/driver.cpp:505

going into the new

>   } else if (!StartedNewLine) {
>     // If we are not on the correct line and don't need to be line-correct,
>     // at least ensure we start on a new line.
>     OS << '\n';
>     StartedNewLine = true;
>   }

block in PrintPPOutputPPCallbacks::MoveToLine

I first reported this in the comment at
<https://reviews.llvm.org/D106924#2919406> "[Preprocessor] -E -P: Ensure
newline after 8 skipped lines" (but without any response yet) where I state how
this breaks the build of LibreOffice.)

(2)  The output now lacks empty lines from the input,

> $ cat test2.c
> foo
> bar
> baz
> $ clang -E -P test2.c
> foo
> bar
> baz

where before that commit it did not,

> $ clang -E -P test2.c
> foo
> bar
> baz

I assume this change was unintentional?  Though note that the test file
clang/test/Preprocessor/skip-empty-lines.c introduced with that commit
authorizes the new behavior, where the COLSONLY lines require no empty line
(from the

> // A single empty line

line in the input) between the lines

>   int  b ;


>   int  c ;

(3)  There is also a pre-existing test file
clang/test/Preprocessor/print_line_track.c with a

>  * RUN: %clang_cc1 -E -P %s | count 4

test, which only happens to still succeed after this commit because the output
changed from

> a 3
> b 16


> a 3
> b 16

(i.e., introducing two empty lines at the top, the first apparently due to (1),
though I didn't check what causes the second one; and dropping the two empty
lines in the middle, apparently due to (2)).

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210825/af0ba1d0/attachment.html>

More information about the llvm-bugs mailing list