Page MenuHomePhabricator

Extend syntax of response files
Needs ReviewPublic

Authored by sepavloff on Jul 29 2017, 1:13 AM.

Details

Reviewers
rnk
rsmith
Summary

This change adds two extensions to the syntax of response files, which are
included into command line by constructs @file. These extensions are:

  • line continuation using trailing backslash, and
  • one line comments started by #.

Processing of response files, made in GCC by libiberty, treats backslash only
as an escape of the next character. It means that using trailing backslash
for line continuation prevents from using files with newline in their names.
Such filenames are rarely used and drop of their support does not look
restrictive.

On Windows backslash is a normal symbol and using it for line split is not
implemented.

Line where the first non-whitespace character is # is considered a
comments and is ignored. This behavior is consistent with sh/ksh/bash on
unix-like systems and PowerShell on Windows. With such extension a file with
name like #file cannot be used at the beginning of line. This problem is
easily solved by using names like ./#file, \#file or by putting file
name in quotes.

Event Timeline

sepavloff created this revision.Jul 29 2017, 1:13 AM

Is there any opinion about feasibility of this extension?
This patch is a prerequisite for D24933 (Enable configuration files in clang), which is now accepted.
If it is not acceptable for all response files, then it must be implemented for config files only.

Is there any opinion about feasibility of this extension?
This patch is a prerequisite for D24933 (Enable configuration files in clang), which is now accepted.
If it is not acceptable for all response files, then it must be implemented for config files only.

I like the extension, but making our parsing of response files differ from GCC's in this regard might not be an improvements (e.g., the handling of the escaped new lines, and even the comments, could be a breaking change). Can you add a new parameter (e.g., bool ExtendedSyntax = false), and then predicate the new behavior on that? Then set that parameter to true when parsing config files from Clang?

I like the extension, but making our parsing of response files differ from GCC's in this regard might not be an improvements (e.g., the handling of the escaped new lines, and even the comments, could be a breaking change). Can you add a new parameter (e.g., bool ExtendedSyntax = false), and then predicate the new behavior on that? Then set that parameter to true when parsing config files from Clang?

This is not a problem, I will revert the other dependency D24926 to its previous version, where config file was parsed by dedicated function.