PrintAsClang is supposed to emit declarations in the same order regardless of the compiler’s internal state, but we have repeatedly found that our current criteria are inadequate, resulting in non-functionality-affecting changes to generated header content. Add a diagnostic that’s emitted when this happens soliciting a bug report.
Since there *should* be no cases where the compiler fails to order declarations, this diagnostic is never actually emitted. Instead, we test this change by enabling `-verify` on nearly all PrintAsClang tests to make sure they are unaffected.
This did demonstrate a missing criterion that only mattered in C++ mode: extensions that varied only in their generic signature were not sorted stably. Add a sort criterion for this.
The new clang implements “P2361 Unevaluated string literals”, which means it rejects numeric escapes in string literals in attributes (most notably for Swift, availability attributes). Update PrintAsClang to follow these new rules when it prints availability attributes. In the case of control characters which cannot be otherwise represented, this means Swift will print a hex code for the user to read.
Fixes rdar://127263671.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
The general policy has been that even if something crashes at run
time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!)
if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought
we could get away with it, and then it turns out it actually caused
some problems. (And as 2bc010681 shows, we can still make mistakes.)
This change isn't perfect because the diagnostic appears in /clients/
rather than in the module that's being compiled as Swift 4 (instead of
Swift 5). But it still means that someone who hasn't changed
/anything/ from a valid Swift 4.0 project will be able to compile
without any changes, even if they were relying on being able to call
+new when -init was unavailable for some reason.
More rdar://problem/35942058
Currently a loop-hole exists by which one could end up invoking an unavailable -init initializer from Obj-C
when it is unavailable by using +new (which itself calls -init)
https://bugs.swift.org/browse/SR-5018
Now that Clang has availability diagnostics too
(-Wpartial-availability and friends) we need to get this correct, or
people will get warnings in the generated header!
rdar://problem/33313703
