maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/FixIt/format.m

257 lines
12 KiB
Mathematica
Raw Normal View History

Update tests touched by r249656 These test updates almost exclusively around the change in behavior around enum: enums without a definition are considered incomplete except when targeting MSVC ABIs. Since these tests are interested in the 'incomplete-enum' behavior, restrict them to %itanium_abi_triple. llvm-svn: 249660
2015-10-08 14:31:22 +08:00
// RUN: %clang_cc1 -triple %itanium_abi_triple -fsyntax-only -fblocks -verify %s
// RUN: %clang_cc1 -triple %itanium_abi_triple -fdiagnostics-parseable-fixits -fblocks %s 2>&1 | FileCheck %s
Suggest '%@' for Objective-C objects in ObjC format strings. llvm-svn: 157716
2012-05-31 05:53:13 +08:00
@class NSString;
extern void NSLog(NSString *, ...);
int printf(const char * restrict, ...) ;
void test_integer_correction (int x) {
printf("%d", x); // no-warning
printf("%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
printf("%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'int'}}
// CHECK: fix-it:"{{.*}}":{10:11-10:13}:"%d"
// CHECK: fix-it:"{{.*}}":{11:11-11:14}:"%d"
NSLog(@"%d", x); // no-warning
NSLog(@"%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'int'}}
NSLog(@"%@", x); // expected-warning{{format specifies type 'id' but the argument has type 'int'}}
// CHECK: fix-it:"{{.*}}":{16:11-16:13}:"%d"
// CHECK: fix-it:"{{.*}}":{17:11-17:14}:"%d"
// CHECK: fix-it:"{{.*}}":{18:11-18:13}:"%d"
}
void test_string_correction (char *x) {
printf("%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'char *'}}
printf("%s", x); // no-warning
printf("%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'char *'}}
// CHECK: fix-it:"{{.*}}":{25:11-25:13}:"%s"
// CHECK: fix-it:"{{.*}}":{27:11-27:14}:"%s"
NSLog(@"%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'char *'}}
NSLog(@"%s", x); // no-warning
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'char *'}}
NSLog(@"%@", x); // expected-warning{{format specifies type 'id' but the argument has type 'char *'}}
// CHECK: fix-it:"{{.*}}":{31:11-31:13}:"%s"
// CHECK: fix-it:"{{.*}}":{33:11-33:14}:"%s"
// CHECK: fix-it:"{{.*}}":{34:11-34:13}:"%s"
}
void test_object_correction (id x) {
NSLog(@"%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'id'}}
NSLog(@"%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'id'}}
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'id'}}
NSLog(@"%@", x); // no-warning
// CHECK: fix-it:"{{.*}}":{41:11-41:13}:"%@"
// CHECK: fix-it:"{{.*}}":{42:11-42:13}:"%@"
// CHECK: fix-it:"{{.*}}":{43:11-43:14}:"%@"
}
typedef const struct __CFString * __attribute__((NSObject)) CFStringRef;
void test_cf_object_correction (CFStringRef x) {
NSLog(@"%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'CFStringRef'}}
NSLog(@"%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'CFStringRef'}}
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'CFStringRef'}}
NSLog(@"%@", x); // no-warning
// CHECK: fix-it:"{{.*}}":{52:11-52:13}:"%@"
// CHECK: fix-it:"{{.*}}":{53:11-53:13}:"%@"
// CHECK: fix-it:"{{.*}}":{54:11-54:14}:"%@"
}
typedef void (^block_t)(void);
void test_block_correction (block_t x) {
NSLog(@"%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'block_t'}}
NSLog(@"%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'block_t'}}
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'block_t'}}
NSLog(@"%@", x); // no-warning
// CHECK: fix-it:"{{.*}}":{63:11-63:13}:"%@"
// CHECK: fix-it:"{{.*}}":{64:11-64:13}:"%@"
// CHECK: fix-it:"{{.*}}":{65:11-65:14}:"%@"
}
Add a test for '%@' suggestion for classes. llvm-svn: 157718
2012-05-31 06:41:32 +08:00
void test_class_correction (Class x) {
NSLog(@"%d", x); // expected-warning{{format specifies type 'int' but the argument has type 'Class'}}
NSLog(@"%s", x); // expected-warning{{format specifies type 'char *' but the argument has type 'Class'}}
NSLog(@"%lf", x); // expected-warning{{format specifies type 'double' but the argument has type 'Class'}}
NSLog(@"%@", x); // no-warning
// CHECK: fix-it:"{{.*}}":{73:11-73:13}:"%@"
// CHECK: fix-it:"{{.*}}":{74:11-74:13}:"%@"
// CHECK: fix-it:"{{.*}}":{75:11-75:14}:"%@"
}
Make suggestions for mismatched enum arguments to printf/scanf. llvm-svn: 157962
2012-06-05 06:49:02 +08:00
typedef enum : int { NSUTF8StringEncoding = 8 } NSStringEncoding;
void test_fixed_enum_correction(NSStringEncoding x) {
Format strings: check against an enum's underlying type. This allows us to be more careful when dealing with enums whose fixed underlying type requires special handling in a format string, like NSInteger. A refinement of r163266 from a year and a half ago, which added the special handling for NSInteger and friends in the first place. <rdar://problem/16616623> llvm-svn: 209966
2014-05-31 12:12:14 +08:00
NSLog(@"%@", x); // expected-warning{{format specifies type 'id' but the argument has underlying type 'int'}}
Make suggestions for mismatched enum arguments to printf/scanf. llvm-svn: 157962
2012-06-05 06:49:02 +08:00
// CHECK: fix-it:"{{.*}}":{85:11-85:13}:"%d"
}
typedef __SIZE_TYPE__ size_t;
enum SomeSize : size_t { IntegerSize = sizeof(int) };
void test_named_fixed_enum_correction(enum SomeSize x) {
Fix test on platforms where size_t is not 'unsigned long'. llvm-svn: 209974
2014-05-31 23:06:33 +08:00
NSLog(@"%@", x); // expected-warning{{format specifies type 'id' but the argument has underlying type 'size_t' (aka}}
Make suggestions for mismatched enum arguments to printf/scanf. llvm-svn: 157962
2012-06-05 06:49:02 +08:00
// CHECK: fix-it:"{{.*}}":{92:11-92:13}:"%zu"
}
Format strings: the correct conversion for 'char' is %c, not %d or %hhd. We tried to account for 'uint8_t' by saying that /typedefs/ of 'char' should be corrected as %hhd rather than %c, but the condition was wrong. llvm-svn: 169397
2012-12-06 02:44:37 +08:00
typedef unsigned char uint8_t;
void test_char(char c, signed char s, unsigned char u, uint8_t n) {
NSLog(@"%s", c); // expected-warning{{format specifies type 'char *' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%lf", c); // expected-warning{{format specifies type 'double' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%c"
NSLog(@"%@", c); // expected-warning{{format specifies type 'id' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%c", c); // no-warning
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%s", s); // expected-warning{{format specifies type 'char *' but the argument has type 'signed char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%lf", s); // expected-warning{{format specifies type 'double' but the argument has type 'signed char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%c"
NSLog(@"%@", s); // expected-warning{{format specifies type 'id' but the argument has type 'signed char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%c", s); // no-warning
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%s", u); // expected-warning{{format specifies type 'char *' but the argument has type 'unsigned char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%lf", u); // expected-warning{{format specifies type 'double' but the argument has type 'unsigned char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%c"
NSLog(@"%@", u); // expected-warning{{format specifies type 'id' but the argument has type 'unsigned char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%c", u); // no-warning
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%s", n); // expected-warning{{format specifies type 'char *' but the argument has type 'uint8_t' (aka 'unsigned char')}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%hhu"
NSLog(@"%lf", n); // expected-warning{{format specifies type 'double' but the argument has type 'uint8_t' (aka 'unsigned char')}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%hhu"
NSLog(@"%@", n); // expected-warning{{format specifies type 'id' but the argument has type 'uint8_t' (aka 'unsigned char')}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%hhu"
NSLog(@"%c", n); // no-warning
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%hhu"
Format strings: a character literal should be printed with %c, not %d. The type of a character literal is 'int' in C, but if the user writes a character /as/ a literal, we should assume they meant it to be a character and not a numeric value, and thus offer %c as a correction rather than %d. There's a special case for multi-character literals (like 'MooV'), which have implementation-defined value and usually cannot be printed with %c. These still use %d as the suggestion. In C++, the type of a character literal is 'char', and so this problem doesn't exist. <rdar://problem/12282316> llvm-svn: 169398
2012-12-06 02:44:40 +08:00
NSLog(@"%s", 'a'); // expected-warning{{format specifies type 'char *' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%lf", 'a'); // expected-warning{{format specifies type 'double' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%c"
NSLog(@"%@", 'a'); // expected-warning{{format specifies type 'id' but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%c", 'a'); // no-warning
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
NSLog(@"%s", 'abcd'); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
NSLog(@"%lf", 'abcd'); // expected-warning{{format specifies type 'double' but the argument has type 'int'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:14}:"%d"
NSLog(@"%@", 'abcd'); // expected-warning{{format specifies type 'id' but the argument has type 'int'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
}
void multichar_constants_false_negative() {
// The value of a multi-character constant is implementation-defined, but
// almost certainly shouldn't be printed with %c. However, the current
// type-checker expects %c to correspond to an integer argument, because
// many C library functions like fgetc() actually return an int (using -1
// as a sentinel).
NSLog(@"%c", 'abcd'); // missing-warning{{format specifies type 'char' but the argument has type 'int'}}
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
Format strings: the correct conversion for 'char' is %c, not %d or %hhd. We tried to account for 'uint8_t' by saying that /typedefs/ of 'char' should be corrected as %hhd rather than %c, but the condition was wrong. llvm-svn: 169397
2012-12-06 02:44:37 +08:00
}
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
void test_percent_C() {
const unsigned short data = 'a';
NSLog(@"%C", data); // no-warning
Special case '%C' handling in ObjC format strings to handle integer literals that can represent unicode characters Fixes <rdar://problem/13991617>. llvm-svn: 192673
2013-10-15 13:25:17 +08:00
NSLog(@"%C", 0x260300); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'int'}}
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:16}:"(unsigned short)"
typedef unsigned short unichar;
Special case '%C' handling in ObjC format strings to handle integer literals that can represent unicode characters Fixes <rdar://problem/13991617>. llvm-svn: 192673
2013-10-15 13:25:17 +08:00
NSLog(@"%C", 0x260300); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'int'}}
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:16}:"(unichar)"
Special case '%C' handling in ObjC format strings to handle integer literals that can represent unicode characters Fixes <rdar://problem/13991617>. llvm-svn: 192673
2013-10-15 13:25:17 +08:00
NSLog(@"%C", data ? 0x2F0000 : 0x260300); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'int'}}
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:16}:"(unichar)("
Special case '%C' handling in ObjC format strings to handle integer literals that can represent unicode characters Fixes <rdar://problem/13991617>. llvm-svn: 192673
2013-10-15 13:25:17 +08:00
// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:42-[[@LINE-3]]:42}:")"
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
NSLog(@"%C", 0.0); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'double'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%f"
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:16}:"(unichar)"
Special case '%C' handling in ObjC format strings to handle integer literals that can represent unicode characters Fixes <rdar://problem/13991617>. llvm-svn: 192673
2013-10-15 13:25:17 +08:00
NSLog(@"%C", (char)0x260300); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'char'}}
Format strings: offer a cast to 'unichar' for %C in Objective-C contexts. For most cases where a conversion specifier doesn't match an argument, we usually guess that the conversion specifier is wrong. However, if the argument is an integer type and the specifier is %C, it's likely the user really did mean to print the integer as a character. (This is more common than %c because there is no way to specify a unichar literal -- you have to write an integer literal, such as '0x2603', and then cast it to unichar.) This does not change the behavior of %S, since there are fewer cases where printing a literal Unicode *string* is necessary, but this could easily be changed in the future. <rdar://problem/11982013> llvm-svn: 169400
2012-12-06 02:44:49 +08:00
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:22}:"(unichar)"
NSLog(@"%C", 'a'); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'char'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%c"
// CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:16-[[@LINE-2]]:22}:"(unichar)"
}
Format strings: correct signedness if already correcting width (%d,%u). It is valid to do this: printf("%u", (int)x); But if we see this: printf("%lu", (int)x); ...our fixit should suggest %d, not %u. llvm-svn: 172739
2013-01-18 02:47:16 +08:00
void testSignedness(long i, unsigned long u) {
printf("%d", u); // expected-warning{{format specifies type 'int' but the argument has type 'unsigned long'}}
printf("%i", u); // expected-warning{{format specifies type 'int' but the argument has type 'unsigned long'}}
printf("%u", i); // expected-warning{{format specifies type 'unsigned int' but the argument has type 'long'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:11-[[@LINE-4]]:13}:"%lu"
// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:11-[[@LINE-4]]:13}:"%lu"
// CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:11-[[@LINE-4]]:13}:"%ld"
Format strings: don't ever convert %+d to %lu. Presumably, if the printf format has the sign explicitly requested, the user wants to treat the data as signed. This is a fix-up for r172739, and also includes several test changes that didn't make it into that commit. llvm-svn: 172762
2013-01-18 06:34:10 +08:00
printf("%+d", u); // expected-warning{{format specifies type 'int' but the argument has type 'unsigned long'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:11-[[@LINE-2]]:14}:"%+ld"
Format strings: correct signedness if already correcting width (%d,%u). It is valid to do this: printf("%u", (int)x); But if we see this: printf("%lu", (int)x); ...our fixit should suggest %d, not %u. llvm-svn: 172739
2013-01-18 02:47:16 +08:00
}
Format strings: check against an enum's underlying type. This allows us to be more careful when dealing with enums whose fixed underlying type requires special handling in a format string, like NSInteger. A refinement of r163266 from a year and a half ago, which added the special handling for NSInteger and friends in the first place. <rdar://problem/16616623> llvm-svn: 209966
2014-05-31 12:12:14 +08:00
void testEnum() {
typedef enum {
ImplicitA = 1,
ImplicitB = 2
} Implicit;
typedef enum {
ImplicitLLA = 0,
ImplicitLLB = ~0ULL
} ImplicitLongLong;
typedef enum : short {
ExplicitA = 0,
ExplicitB
} ExplicitShort;
printf("%f", (Implicit)0); // expected-warning{{format specifies type 'double' but the argument has underlying type}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%{{[du]}}"
printf("%f", (ImplicitLongLong)0); // expected-warning{{format specifies type 'double' but the argument has underlying type}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%{{l*[du]}}"
printf("%f", (ExplicitShort)0); // expected-warning{{format specifies type 'double' but the argument has underlying type 'short'}}
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%hd"
}