This is an archive of the discontinued LLVM Phabricator instance.

[lit] Correctly expand globs relative to their intended directory.
Needs ReviewPublic

Authored by graydon on Sep 5 2018, 4:44 PM.

Details

Reviewers
ddunbar
Summary

Lit emulates shell semantics in its RUN: line interpretation. As
part of this emulation, it sniffs 'cd' commands in the command
to execute (such as "cd /some/path && ...") and then uses the
argument to 'cd' as a directory in which it interprets subsequent
elements of the command, in particular globs.

When expanding a non-absolute (relative) glob, however, it currently
takes a naive and (I argue) incorrect approach to them: it prepends
the inferred working directory's absolute path to the glob and then
expands the glob as an absolute path. This identifies the correct
_files_ but it names them absolutely, where the glob was written
as a relative glob. In a few corner cases, the difference between
an absolute and a relative filename is _meaningful_ to the program
under test, and should be preserved even when expanding globs.

This change works by stripping the absolute prefix back off the
expansion of a relative glob (using relpath), which makes the
behaviour at least more shell-like.

Diff Detail

Event Timeline

graydon created this revision.Sep 5 2018, 4:44 PM
graydon updated this revision to Diff 164127.Sep 5 2018, 4:52 PM

Add test, fix typo.

For context, the motivation here is a somewhat subtle testcase over in swift driver land in which we need to construct an argv for the driver that is not longer than kern.maxarg, but that will be transformed into such an over-long argv when composed with an absolute output directory and passed to a frontend. This test has been flaky on CI because we were globbing the input to the driver (under a "cd ... && ...") and lit was sticking the absolute path of the testsuite-on-the-CI-machine on the front of all the globbed inputs. Sometimes this meant the input argv to the driver would overflow, other times not; depends on which CI host and subdir it's running inside of. Obviously not great.

See https://github.com/apple/swift/pull/19149 for current workaround on swift side. I'm also fixing it here so that nobody has to hunt this particular family of errors down again.