-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Fix Unicode Tests on Windows #23040
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Unicode Tests on Windows #23040
Conversation
test/stdlib/UnicodeMetadata.swift
Outdated
@@ -1,4 +1,4 @@ | |||
// RUN: %target-build-swift -module-name="日本語01" %s -o %t.out | |||
// RUN: %target-build-swift "@%/S/Inputs/Unicode.resp" %s -o %t.out |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The check // CHECK: [日本語01.myClass]
in this file is checking against UTF-8 bytes. This prints out UTF-8 bytes on Windows, so that passes the check, but I wasn't entirely sure of the intended behaviour. Actually running it prints out a badly encoded mess.
S:\b\swift> &"s:\b\swift\test-windows-x86_64\stdlib\Output\UnicodeMetadata.swift.tmp.out.exe"
[日本語01.myClass]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, but probably correct. I think we assume our output streams are UTF-8ish now. @milseman?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't made any changes there. I believe it's been the case since before I started working on the project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, just wanted to know if that was an assumption we were already making. Thanks!
e30ad9d
to
2d6f1ff
Compare
2d6f1ff
to
16dc909
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this seems reasonable!
// CHECK-NEXT: "command_arguments": [ | ||
// CHECK-NEXT: "{{.*[\\/]}}你好-[[OUTPUT]].o", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What changed here such that this is no longer the next line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It passes -target
which comes first.
@swift-ci Please smoke test |
Whew did I learn far more than I could have ever wanted about Unicode.
Requires apple/swift-llvm#142 to go in to make the tests pass on Windows.
With python 2, lit still passes the arguments as utf-8 encoded bytes which is an issue on Windows. It wouldn't be too difficult of a fix, however, the gnu core-utils on Windows (ls being the one I ran into) don't understand UTF16 command line arguments and fail. To work around this, I've passed the arguments in response files. Alternatively, we'd either have to implement ls in lit, or (maybe more fun) in swift.