[llvm-bugs] [Bug 50151] New: clangd doesn't import preprocessed file like cland does when using -include

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50151

            Bug ID: 50151
           Summary: clangd doesn't import preprocessed file like cland
                    does when using -include
           Product: clang-tools-extra
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: clangd
          Assignee: unassignedclangbugs at nondot.org
          Reporter: romain.geissler at amadeus.com
                CC: llvm-bugs at lists.llvm.org

Hi,

Some users of clangd in my company reported me that clangd may have some
trouble to preprocess some files that we do compile in a quite strange way.

We do compile our headers to check that they:
 - build correctly (more or less like with -fsyntax-only)
 - they don't generate warnings for people who would include it later in other
projects (and with gcc, some warnings are visible only after you actually
generate code, and sometimes only with -O2, so -fsyntax-only is not enought, we
really create an actual .o file which we actually don't use).

Also to cope with the fact that normally things like "#pragma once" shall not
appear in a .cpp, and since gcc (that we use) lacks a clang version of
-Wno-pragma-once-outside-header we had to rely on "compiling our headers" the
following strange way:

$CXX -o file.hpp.o -include file.hpp -c empty.cpp

where empty.cpp is just an empty file. From a compiler point of view, this is
perfectly valid despite being strange.

However when trying this with clangd, we end up actually including file.hpp
twice (and things like #pragma once or header guards are ignored), and clangd
ends up reporting redefinition errors in the diagnostics. This happens as some
of our users also do want to index their headers (which might actually be
included by no .cpp files, but still exists as some user library might actually
use these headers). I am wondering if there is anything that could be done on
clangd side to help handling these strange corner case that are working with
the compilers.

Easy way to reproduce (I will assume the current working directory is
/remote/users/rgeissler/wk/tmp/BMS-3145):
 - Create all these files with these content:

rgeissler at ncerndobedev6097:~/wk/tmp/BMS-3145> ls
compile_commands.json  empty.cpp  file.h  input
rgeissler at ncerndobedev6097:~/wk/tmp/BMS-3145> cat empty.cpp
rgeissler at ncerndobedev6097:~/wk/tmp/BMS-3145> cat file.h
#pragma once
class SomeClass{};
rgeissler at ncerndobedev6097:~/wk/tmp/BMS-3145> cat compile_commands.json
[
    {
        "directory" : "/remote/users/rgeissler/wk/tmp/BMS-3145",
        "command" : "g++ -o file.o -include file.h -c empty.cpp",               
        "file" : "file.h"
    }
]
rgeissler at ncerndobedev6097:~/wk/tmp/BMS-3145> cat input                        
                                                                               
              2:24PM
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"initializationOptions":{"compilationDatabasePath":"."}}} 
--- 
{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"file:///remote/users/rgeissler/wk/tmp/BMS-3145/file.h","languageId":"cpp","version":1,"text":"#pragma
once\nclass SomeClass{};\n"}}}
---     
{"jsonrpc":"2.0","id":10000,"method":"shutdown"}
--- 
{"jsonrpc":"2.0","method":"exit"}

 - Run it like this: /path/to/clangd -lit-test < input

Which with clangd 12 will emit something like:

{
  "jsonrpc": "2.0",
  "method": "textDocument/publishDiagnostics",
  "params": {
    "diagnostics": [
      {
        "code": "redefinition",
        "message": "Redefinition of
'SomeClass'\n\n/remote/users/rgeissler/wk/tmp/BMS-3145/file.h:2:7:\nnote:
previous definition is here",
        "range": {
          "end": {
            "character": 15,
            "line": 1
          },
          "start": {
            "character": 6,
            "line": 1
          } 
        },
        "severity": 1,
        "source": "clang"
      } 
    ],
    "uri": "file:///remote/users/rgeissler/wk/tmp/BMS-3145/file.h",
    "version": 1
  }
}

while we expect no diagsnotic issue at all.

Cheers,
Romain

-- 
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/20210428/128fcc7d/attachment.html>