As part of my patches to the AST parsing for 16 bit, the main code is ready for PR but I need to write unit tests and update the one that's there.
test/Parse/builtin_word.swift
Has lines like:
// RUN: %target-typecheck-verify-swift -parse-stdlib
word = Builtin.truncOrBitCast_Int128_Word(i128)
word = Builtin.truncOrBitCast_Int64_Word(i64)
word = Builtin.truncOrBitCast_Int32_Word(i32) // expected-error{{}}
word = Builtin.truncOrBitCast_Int16_Word(i16) // expected-error{{}}
I'd like to change the tests because the errors will depend on the target pointer length now. For 32 bit arch, Builtin.truncOrBitCast_Int32_Word(i32) should not report an error, for 64 bit arch, it should.
I'm somewhat familiar with llvm-lit/FileCheck but I have not seen the "expected-error" construct before. I can guess what it does but how would I make it platform specific?
From the swift Testing.md document, I'd usually expect to use something like...
// RUN: %target-swift-frontend ... | %FileCheck --check-prefix=CHECK --check-prefix=CHECK-%target-ptrsize %s
// CHECK: common line
// CHECK-32: only for 32-bit
// CHECK-64: only for 64-bit
But I'm not sure how that applies to this "expected-error" construct?
When you pass -verify to the frontend (which in your case is one of the things implied by %target-typecheck-verify-swift -parse-stdlib), the diagnostics engine stops reporting diagnostics normally and instead displays diagnostics if the normal diagnostics from the frontend don't match the expected lines in the file. It has nothing to do with FileCheck.
There are some kinds of conditionalization built-in to -verify, but I don't think the target is one of them. The easiest way to get that conditionalization is to make different test files and either (1) hard-code what target they use or (2) use REQUIRES/UNSUPPORTED to get lit to ignore them when the target isn't right. Alternatively, you can use gyb to change the actual contents of the test file based on the current target; or if you're really motivated, you can improve the diagnostics verifier (DiagnosticVerifier.cpp) to allow target-based conditionalization.
A perfect, concise and fast answer, as usual. Thanks @John_McCall.
I think I'm fairly highly motivated but for now I'll create separate, hard coded tests, each with REQUIRES. It isn't a huge number of tests and it'll be a lot clearer than a .gyb file. Plus shouldn't change much in future so maintenance won't be burden.
