This is an archive of the discontinued LLVM Phabricator instance.

Fix PR17239 by changing the semantics of the RemainingArgsClass Option kind (clang side)
ClosedPublic

Authored by rafaelauler on Aug 13 2014, 10:25 PM.

Details

Summary

This is the Clang side of the patch in http://reviews.llvm.org/D4899

This patch aims at fixing PR17239.

Note: it depends on http://reviews.llvm.org/D4899 the llvm side of the patch, landing in the LLVM tree.

This bug happens because the /link (clang-cl.exe argument) is marked as "consume all remaining arguments". However, when inside a response file, /link should only consume all remaining arguments inside the response file where it is located, not the entire command line after expansion. The LLVM side of the patch will change the semantics of the RemainingArgsClass kind to always consume only until the end of the response file when the option originally came from a response file. There are only two options in this class: dash dash (--) and /link.

In the Clang side, I just used the ExpandedArgs class created in the LLVM side of the patch to fix this bug.

Diff Detail

Event Timeline

rafaelauler retitled this revision from to Fix PR17239 by changing the semantics of the RemainingArgsClass Option kind (clang side).
rafaelauler updated this object.
rafaelauler edited the test plan for this revision. (Show Details)
rafaelauler added a reviewer: rafael.
rafaelauler added a subscriber: Unknown Object (MLST).

This is the clang side of my updated patch in D4899. I updated the Driver to cope with the new LLVM API proposed in that patch:

  • Call ExpandResponseFiles with MarkEOLs set to true to allow correct expansion of the /LINK argument, fixing PR17239. Only do this for the clang driver, not for clang -cc1 tools.
  • Ignore nullptrs in the argv vector because they are now used to indicate end of lines.

I also updated the Driver::ParseArgStrings parameter name that had a confusing argument name that was the same of a known class used in the same scope (NFC).

rnk accepted this revision.Aug 22 2014, 11:45 AM
rnk added a reviewer: rnk.
rnk added a subscriber: rnk.

This is tied to D4899, so I'll land it too. Thanks!

tools/driver/driver.cpp
406–409

This seems impossible. If we invoked a cc1 tool, we shouldn't have added EOL markers, right?

This revision is now accepted and ready to land.Aug 22 2014, 11:45 AM

Hi Reid,

Sure, thanks for reviewing it. I answered your comment below.

tools/driver/driver.cpp
406–409

I made this check just in case the user puts "-cc1" as a first argument in a response file. In this case, MarkEOLs would be true. After expanding the response files, we would end up here with MarkEOLs true (a contrived example, but possible).

rnk closed this revision.Aug 22 2014, 2:53 PM

Landed in r216281.

tools/driver/driver.cpp
406–409

OK, I added a test case for it and will commit it soon.