GeezerVison

This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve

I don't think this implements what #174 asks for. gcc -E -P suppresses the linemarkers in the output; it does not ignore #line directives in the input. In simplecpp the output markers come from TokenList::stringify(), which writes #line N "file" whenever the file changes or the line goes backwards. Those are untouched by this PR, so includes still produce markers:

$ cat a.h
int h;
$ cat m.c
#include "a.h"
int x;
#line 10 "foo.c"
int y;
$ ./simplecpp -P m.c

#line 1 "a.h"
int h ;
#line 2 "m.c"
int x ;

int y ;

Ignoring input #line also changes semantics in a way gcc's -P does not: __LINE__/__FILE__ and the locations in error messages no longer follow the #line directive (with gcc -E -P, #line 10 "foo.c" still affects __LINE__/__FILE__).

Suggestion: make this an output option instead, e.g. a parameter to stringify() (or a separate print loop in main.cpp) that skips writing the #line markers, and leave the tokenizer/DUI unchanged.

This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve

Passing dui here instead of {} changes behaviour for all library users, not just -P: readfile() uses dui.std for the #line portability diagnostics, so headers will now get std-specific messages they didn't get before. That may be a good change, but it is unrelated to -P. If the option becomes output-only (see the other comment), this change isn't needed. If it is kept, it would be good to mention it in the PR description and add a test for it.

This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve

This test only covers a #line directive in the main file. The more common case for -P (e.g. creduce input) is output that crosses #include boundaries, and that currently still prints #line markers. A test that uses an include, and checks that the stringified output has no #line lines, would catch that.