This is an archive of the discontinued LLVM Phabricator instance.

[libcxx][lit] Simplify parsing of trailing executor arguments
ClosedPublic

Authored by arichardson on Jul 18 2020, 5:52 AM.

Details

Summary

Adding a positional argparse.ONE_OR_MORE arguments will correctly remove
the "--" separator after --env and parse only the command. This also has
the advantage that misspelled flags raise an argparse error rather than
silently being added to the command to be executed.

I discovered this while adding a new commandline option to ssh.py to allow
passing additional arguments to the scp/ssh commands since this is required
for our CHERI CI where we need to pass -F <custom_config_file> to each
ssh/scp command to set various arguments such as the localhost port, usage
of controlmaster, etc. to speed up connections to our emulated QEMU systems.

Diff Detail

Event Timeline

arichardson created this revision.Jul 18 2020, 5:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2020, 5:52 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript
ldionne requested changes to this revision.Jul 20 2020, 5:31 AM

That's a nice cleanup! Only a nitpick.

libcxx/utils/run.py
25–26

No need for the comment anymore.

This revision now requires changes to proceed.Jul 20 2020, 5:31 AM

remove unnecessary code now that argparse checks that at least one command argument is present

ldionne accepted this revision.Jul 20 2020, 8:07 AM

Do you have commit access? If not, please specify the Author Name <email@email.com> I should use.

This revision is now accepted and ready to land.Jul 20 2020, 8:07 AM

Do you have commit access? If not, please specify the Author Name <email@email.com> I should use.

Yes, I do. Will commit shortly.

This revision was automatically updated to reflect the committed changes.

I noticed that llvm/libcxx/test/std/thread/thread.mutex/thread.mutex.requirements/thread.timedmutex.requirements/thread.timedmutex.class/lock.pass.cpp failed after my commit, but it seems to me that this test (and all the others in that directory) should not be assuming that the wait will be less than x milliseconds. I believe I worked around this in our CHERI fork by increasing the timeout for slow emulated systems, but that could still fail in some cases.