This is an archive of the discontinued LLVM Phabricator instance.

Extend CompilationDatabase by a field for the output filename
ClosedPublic

Authored by joerg on Nov 25 2016, 1:29 PM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

joerg updated this revision to Diff 79320.Nov 25 2016, 1:29 PM
joerg retitled this revision from to Extend CompilationDatabase by a field for the output filename.
joerg updated this object.
joerg added a reviewer: klimek.
joerg set the repository for this revision to rL LLVM.
joerg added a subscriber: cfe-commits.
klimek added inline comments.Nov 28 2016, 1:57 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

Optional: I'd probably let the nodeToCommandLine handle the null value and make this code more straight forward?

joerg added inline comments.Nov 28 2016, 4:08 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

I couldn't find a way to create a synthetic node without changing the YAML API.

klimek added inline comments.Nov 28 2016, 4:49 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

I'm probably missing something - why would we need a synthetic node? Can't we just put nullptr into the vector?

joerg added inline comments.Nov 28 2016, 7:33 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

That's what I am doing and why this line checks output :)

klimek added inline comments.Nov 28 2016, 7:38 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

Ok, let's ask differently: why is it a problem if we put a nullptr into the array?

joerg added inline comments.Nov 28 2016, 7:50 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

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.

joerg added a comment.Nov 28 2016, 3:52 PM

Can I interprete that as LGTM otherwise?

klimek added inline comments.Nov 29 2016, 5:28 AM
lib/Tooling/JSONCompilationDatabase.cpp
266 ↗(On Diff #79320)

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?

joerg added a comment.Nov 29 2016, 6:30 AM

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.

klimek edited edge metadata.Nov 29 2016, 6:44 AM

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:

  1. if it doesn't exist, have nullptr in the struct
  2. if it exists and is empty (""), have the empty string in the struct (and potentially give the user an error)
  3. if it exists and is non-empty, all is good
joerg added a comment.Nov 29 2016, 7:21 AM

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.

klimek accepted this revision.Dec 1 2016, 3:52 AM
klimek edited edge metadata.

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.

Ok, you convinced me. LG then.

This revision is now accepted and ready to land.Dec 1 2016, 3:52 AM
This revision was automatically updated to reflect the committed changes.