Support spaces in filepaths with Args object

[keith]

Description of the problem / feature request:

Currently if you add filepaths that include spaces to an Args object and then configure it to be output to a file, the file paths are not quoted or escaped, which can lead to issues with the tools that end up consuming the files.

Feature requests: what underlying problem are you trying to solve with this feature?

swiftc and clang are examples of compiles that accept these files, but don't support file paths with spaces in the multiline format.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Using rules_swift and Xcode 10, build a project that has a Swift source file with spaces in the file path. You will hit this codepath which will result in a compiler error as it tries to pass the files splitting at the space

What operating system are you running Bazel on?

macOS 10.13

What's the output of bazel info release?

release 0.17.1

Migrated this issue from here https://github.com/bazelbuild/rules_swift/issues/60

[keith]

It looks like based on the documentation here, this might be an intentional difference with the multiline format vs the shell format. Although it seems like in this case the multiline format would always require the consumer to correctly quote any arguments as needed. Is this the intention?

[allevato]

The underlying ParameterFile implementation seems to confirm this. That being said, I think it would be unfortunate if the only way to get quoted paths is to give up multi-line params files, because multi-line files are much easier to work with when debugging or diagnosing problems.

I can't speak for all tools, but LLVM/Clang/Swift at least use binutils buildargv/expandargv semantics for params files, which support any ANSI whitespace between arguments (space \t \n \r \f \v), so it would still be possible to quote them in multi-line mode.

@tomlu What do you think?

[tomlu]

It seems like a fairly pedestrian problem. I'm mostly a performance guy and this doesn't really affect performance. The exact format is between the rule author and their tools.

Put in a FR with a motivation and we'll see what the starlark guys say.

On Mon, Sep 24, 2018, 22:56 Tony Allevato notifications@github.com wrote:

The underlying ParameterFile https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/actions/ParameterFile.java implementation seems to confirm this. That being said, I think it would be unfortunate if the only way to get quoted paths is to give up multi-line params files, because multi-line files are much easier to work with when debugging or diagnosing problems.

I can't speak for all tools, but LLVM/Clang/Swift at least use binutils buildargv/expandargv semantics for params files, which support any ANSI whitespace between arguments (space \t \n \r \f \v https://github.com/gcc-mirror/gcc/blob/master/include/safe-ctype.h#L65), so it would still be possible to quote them in multi-line mode.

@tomlu https://github.com/tomlu What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/6224#issuecomment-424191187, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbnSr3ckpaInLVXCQx4AU0URIE92Dqsks5ueZt0gaJpZM4W3l-x .

[comius]

I think of there are fair amount of fairly popular tools creating a implicit standard for params file format, also Bazel could support that as new params file format.

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.