This is an archive of the discontinued LLVM Phabricator instance.

Make lit TestRunner.py work in Python 3
ClosedPublic

Authored by hlopko on Jun 8 2020, 12:03 AM.

Details

Summary

In Python3 SubstituteCaptures are no longer converted to String implicitly behind the scenes. Converting explicitly makes the TestRunner to work in Python3.

Diff Detail

Event Timeline

hlopko created this revision.Jun 8 2020, 12:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 8 2020, 12:03 AM
hlopko retitled this revision from Make lit test runner work in python 3 to Make lit TestRunner.py work in Python 3.Jun 8 2020, 12:18 AM
hlopko added a reviewer: gribozavr2.
hlopko edited the summary of this revision. (Show Details)

Instead of adding a cast at the point where the value is used, I think it is usually better to fix callers to cast the values themselves.

tbkka added a subscriber: tbkka.Jul 16 2020, 9:39 AM

Swift uses a wrapper object to track certain types of transforms. We could in theory overhaul Swift's use of lit to avoid that, but it would be a much bigger change.

Here are some more details:

Swift's lit.cfg wraps certain substitutions in a class that is part of LLVM's lit implementation (specifically class SubstituteCaptures from TestingConfig.py). This class breaks the logic in TestRunner.py on Python3: Python 2.7's regex always stringified its arguments implicitly; Python3 does not. Apparently, the SubstituteCaptures class is not currently used anywhere in LLVM itself, which is why this mismatch isn't breaking LLVM builds.

I'm not sure if the early string conversion would work. The problem is that the \ replacement would escape the backreference. So you end up with problems in the back-reference. The wrapper ensures that they do not get replaced away as the path separator.

I agree with @tbkka about this being the most concise approach to solving the issue.

@gribozavr2, do you have any other suggestions on how to handle that?

gribozavr2 accepted this revision.Jul 22 2020, 1:05 AM

Generally in Python it is preferred to have more strongly typed inputs than stringifying whatever comes in. If you feel like this is the best choice, I don't mind.

This revision is now accepted and ready to land.Jul 22 2020, 1:05 AM
This revision was automatically updated to reflect the committed changes.