Bug-Point functionality needs extending due to the patch D29185 by bd1976llvm (Allow llvm's build and test systems to support paths with spaces ). It requires Bugpoint to accept the use of spaces within ‘--compile-command’ tokens.
Details
Bugpoint uses the argument ‘--compile-command’ to pass in a command line argument as a string, the string is tokenized by the ‘lexCommand’ function using spaces as a delimiter. Patch D29185 will cause the unit test compile-custom.ll to fail as spaces are now required within tokens and as a delimiter. This patch allows the use of escape characters as below:
Two consecutive '\' evaluate to a single '\'.
A space after a '\' evaluates to a space that is not interpreted as a delimiter.
Any other instances of the '\' character are removed.
Testing
As I explain below, testing may be difficult:
- This change is not dependant on the D29185 patch
- When using a path with no spaces D29185 introduces no new test failures, using a path with spaces will cause a Bugpoint test failure (compile-custom.ll)
- In the review for D29185, Chandlerc makes a point regarding internal paths still not requiring use of spaces. A system test for the new Bugpoint behaviour would not adhere to this
- Bugpoint has no unit tests, it seems out of the scope of this change to create some now
A solution may be using the build bot described in the review of D29185, one that uses a path with spaces. If this patch behaviour changes the build bot will act as a regression test, with the Bugpoint test failing as before.
Any suggestions would be appreciated.
You may consider factoring out CommandLine[Pos] (as in char C = CommandLine[Pos]; in the first line of the loop).