In bigger projects like an Operating System, the same source code is often compiled in slightly different ways. This could be the difference between PIC and non-PIC code for static vs dynamic libraries, it could also be the difference between size optimised versions of tools for ramdisk images. At the moment, the compilation database has no way to distinguish such cases. As first step, add a field in the JSON format for it and process it accordingly.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | Optional: I'd probably let the nodeToCommandLine handle the null value and make this code more straight forward? |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | I couldn't find a way to create a synthetic node without changing the YAML API. |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | I'm probably missing something - why would we need a synthetic node? Can't we just put nullptr into the vector? |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | That's what I am doing and why this line checks output :) |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | Ok, let's ask differently: why is it a problem if we put a nullptr into the array? |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | I think it just adds unnecessary complexity. An empty file name is not a valid output, so "" vs Optional has the same result. I'd have prefered to keep this complexity inside the JSON parser, but that would have meant creating a synthetic node with value "" and there is no API for that at the moment. |
lib/Tooling/JSONCompilationDatabase.cpp | ||
---|---|---|
266 | Don't we thus want to actually be able to err out on a higher level when getting an empty output dir, but be OK with an unspecified (-> nullptr) one? |
It's not the directory, but the output file. That's optional since it is a new addition and I don't want to invalidate all existing JSON databases.
It seems like we're talking past each other. I'm not suggesting to invalidate all existing JSON databases. I'm suggesting:
- if it doesn't exist, have nullptr in the struct
- if it exists and is empty (""), have the empty string in the struct (and potentially give the user an error)
- if it exists and is non-empty, all is good
Which struct are we talking about, CompileCommandRef or CompileCommand? It is a pointer in the former and a plain StringRef in the latter. I don't think making it a pointer in both is an advantage, i.e. distinguishing empty input from missing field is not valuable in my opinion.
Optional: I'd probably let the nodeToCommandLine handle the null value and make this code more straight forward?