[win][test] Make PathSanitizingFileCheck more aware of Windows. #24940
Conversation
|
|
||
| // RUN: cd %t && %swiftc_driver -driver-print-jobs -working-directory %/S/Inputs -c %/s -enable-bridging-pch -import-objc-header bridging-header.h | %FileCheck %s -check-prefix=OBJC_HEADER2 | ||
| // OBJC_HEADER2: SOURCE_DIR/test/Driver/Inputs{{/|\\\\}}bridging-header.h{{"? .*}}-emit-pch | ||
| // OBJC_HEADER2: SOURCE_DIR/test/Driver/Inputs/bridging-header.h{{"?}} {{.*}}-emit-pch |
There was a problem hiding this comment.
Because it is two different things: the path SOURCE_DIR/test/Driver/Inputs/bridging-header.h with a possible end quote, and some other path that finishes in -emit-pch. It might not be a necessary change, but it makes it clear that there's two "atoms" to check for. The other way it looks like it is part of the same thing.
| @@ -60,9 +60,11 @@ constants.""") | |||
|
|
|||
| if args.enable_windows_compatibility: | |||
| if args.enable_yaml_compatibility: | |||
| slashes_re = r'(/|\\\\|\\\\\\\\)' | |||
| slashes_re = r'(/|\\\\\\\\|\\\\)' | |||
There was a problem hiding this comment.
At first I was trying to use the same regular expression for both cases, Having the 2 escaped slashes before the 4 escaped slashes was creating duplicated / as a result. Since the extra / was not necessary, I finally decided to split it into two regular expressions, and I didn't undo this change.
| if args.enable_windows_compatibility: | ||
| # For making easier to write the tests, we also look in the | ||
| # possible subpath attached to the replacement. | ||
| extended_replacement = replacement + r'[^\s\'"]+' |
There was a problem hiding this comment.
Why do we need to deal with the quoting now when we didn't previously?
There was a problem hiding this comment.
We are not doing something that we weren't doing before.
Before, the only thing that we were doing was matching the path found in the result and transforming it into the tokens SOURCE_DIR or BUILD_DIR. If the output had c:\s\b\swift it was replaced by BUILD_DIR.
This new piece of code does something similar, but not the same: it looks for things that starts with BUILD_DIR (for example) and keeps looking until it finds an space, or some quote. Then it replaces all the \ in there for the Unix /, so they match the tests. The space and the quotes are the typical stop characters for paths, and the ones that cover all the cases I could find in the existing tests.
In summary: first replacement replaces c:\s\b\swift\foo\bar\baz into BUILD_DIR\foo\bar\baz, and the second takes that result and replaces it for BUILD_DIR/foo/bar/baz. Technically you can try to do both at the same time, but I wanted to not modify the Unix path, if possible. This is clearly under the Windows compatibility mode.
|
@swift-ci please smoke test |
Besides being smart about directory separators in Windows for the replacements, the PathSanitizingFileCheck will also look into the path attached to the replacements, and try to do the same trick there, to avoid littering every test with checks for both directory separators.
drodriguez
force-pushed
the
windows-more-path-sanitizing
branch
from
415d9ea to
7cb31ab
Compare
|
@swift-ci please smoke test |
|
@swift-ci Please smoke test OS X platform |
|
Abandoning this change. I think this is safer than #25546, and it includes a couple of pieces that should clean up a little, but having a half-solution were one have to remember to add the patterns to some checks but not other doesn’t seem like the best solution. |
Besides being smart about directory separators in Windows for the
replacements, the PathSanitizingFileCheck will also look into the path
attached to the replacements, and try to do the same trick there, to
avoid littering every test with checks for both directory separators.
The change in
lit.cfgavoids using Python '%r' since it is supposed to be used only for getting serialized Python objects, so the escaping is right for Python, but not for the shell, since it does more than needed (like escaping \ Windows separators).pipes.quoteis used instead to escape it properly. All those %r should be removed, but for the time being, I only removed the ones related to path sanitizing.This removes a few of those
{{/|\\}}and their variants, but not all. I think all of them can be removed being more aggressive, but I have to work more on that. At least this should avoid problems like #24931. I tested all those changes in my Windows installation.