Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com> Message-ID: In-Reply-To: <llvm/llvm-project/pull/66514/cl...@github.com>
tbaederr wrote: > > > I have concerns about Lexing twice every single file for which we display > > > a warning. > > > > > > Sure. Because of performance, memory usage or code complexity? > > Performance, mostly In a debug build with sanitizers enabled, I get this when compiling `SemaExpr.cpp` from clang with a `static_assert(false)` added at the end: ``` /home/tbaeder/code/llvm-project/clang/lib/Sema/SemaExpr.cpp:21870:15: error: static assertion failed Lexed 21870 lines and 174105 Tokens That took 660402 microseconds That took 660 milliseconds That took 0 seconds ``` That doesn't seem too bad to me? I can try again with an optimized build if you want. > > So, my general procedure for diagnostics is that they shouldn't complicate > > the non-diagnostic code. And when we emit a diagnostic, performance is > > basically out the window anyway (printing to stdout is _slow_ and the way > > we emit code snippets is also slow, etc.) > > That is generally true, but how far do want to push that logic? Lexing is > going to be fairly expensive on most source files. I'd expect it to be much > more (cpu) expensive than a call to print. Of course it's more expensive, I was just trying to make a point :) I expect this to be only visible in situations where very few errors are ever shown, i.e. when an actual human compiles a project. Build servers redirect the output to a file anyway, which disables any sort of colored output. https://github.com/llvm/llvm-project/pull/66514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
