I test the case "tuple_arguments.swift" for v4.0 and found it is failed
when the swift compiler is built in "-d" debug mode, but it is passed
when built in release mode.
Here is a simple test case:
// SR-4738
let sr4738 = (1, (2, 3))
[sr4738].map { (x, (y, z)) -> Int in x + y + z } // expected-error {{use
of undeclared type 'y'}}
// expected-error@-1 {{closure tuple parameter does not support
destructuring}} {{20-26=arg1}} {{38-38=let (y, z) = arg1
; }}
Save it to a file (for example, tt.swift), then run following commands:
If "swift" compiler is built with debug mode ("-d"), then got following
output:
tt.swift:5:96: error: expected fix-it not seen; actual fix-its:
{{20-26=arg1}} {{38-38=let = arg1; }}
.....
Stack dump:
0. Program arguments: swift -frontend -target
x86_64-unknown-linux-gnu -module-cache-path /tmp/ -swift-version 3
-typecheck -verify -disable-objc-attr-requires-foundation-module
tt.swift -swift-version 4
Aborted (core dumped)
The testing "lib/Frontend/DiagnosticVerifier.cpp:: checkForFixIt" gives
that
the "ActualFixIt" is "let " and "Expected" is "let (y, z) = arg1", and
then causes "core dumped" in an assert.
However the both "ActualFixIt" and "Expected" match when the "swift" is
built in release mode.
Note that the all "fixed-it"s are stored in a list, originally is added by
"DiagnosticVerifier::addDiagnostic"
Can anyone let me know how the compiler build options affect the test
results.
I tested the same case on s390x and found the similar errors.
Thanks,
Sam Ding,
Linux on z Systems Open Source Ecosystem
IBM Toronto Lab,
email: samding@ca.ibm.com
phone: (905)413-2947
That error looks like the swift compiler frontend process is crashing during the test. The build configuration of the compiler can definitely affect crashes of the compiler itself. Have you filed a bug report?
···
On Oct 16, 2017, at 9:20 AM, Sam Ding via swift-dev <swift-dev@swift.org> wrote:
I test the case "tuple_arguments.swift" for v4.0 and found it is failed when the swift compiler is built in "-d" debug mode, but it is passed
when built in release mode.
Here is a simple test case:
// SR-4738
let sr4738 = (1, (2, 3))
[sr4738].map { (x, (y, z)) -> Int in x + y + z } // expected-error {{use of undeclared type 'y'}}
// expected-error@-1 {{closure tuple parameter does not support destructuring}} {{20-26=arg1}} {{38-38=let (y, z) = arg1
; }}
Save it to a file (for example, tt.swift), then run following commands:
If "swift" compiler is built with debug mode ("-d"), then got following output:
tt.swift:5:96: error: expected fix-it not seen; actual fix-its: {{20-26=arg1}} {{38-38=let = arg1; }}
.....
Stack dump:
0. Program arguments: swift -frontend -target x86_64-unknown-linux-gnu -module-cache-path /tmp/ -swift-version 3 -typecheck -verify -disable-objc-attr-requires-foundation-module tt.swift -swift-version 4
Aborted (core dumped)
The testing "lib/Frontend/DiagnosticVerifier.cpp:: checkForFixIt" gives that
the "ActualFixIt" is "let " and "Expected" is "let (y, z) = arg1", and then causes "core dumped" in an assert.
However the both "ActualFixIt" and "Expected" match when the "swift" is built in release mode.
Note that the all "fixed-it"s are stored in a list, originally is added by "DiagnosticVerifier::addDiagnostic"
Can anyone let me know how the compiler build options affect the test results.
I tested the same case on s390x and found the similar errors.