Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
This eliminates the need for an ugly and incomplete hack to suppress
noescape inference for setter arguments. It also means we stop emitting
redundant diagnostics for problems in storage types.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
* [ClangImporter] Remove importer-based NS stripping.
As Tony puts it, in the end we wound up with more Foundation
declarations imported as members or keeping "NS" than those that
dropped it, and any further decisions will be made on a case-by-case
basis. Move all of the existing cases of prefix-stripping into
Foundation's API notes and drop the logic from the compiler.
Tested by dumping the generated interface for Foundation and its
submodules for both macOS and the iOS simulator, and comparing the
results. A few cases did slip through here because of the interaction
between "SwiftName" and "Availability: nonswift".
The next commit will re-add "NS" to some stragglers that we missed.
rdar://problem/26880017
* APINotes: Add "NS" back to a few types.
NSKeyedUnarchiverDelegate
NSKeyedArchiverDelegate
NSTextCheckingTypes
NSBinarySearchingOptions
NSEnumerationOptions
NSSortOptions
More rdar://problem/26880017
* Remove now-redundant SwiftNames from API notes.
No change observed in the generated interface of Foundation and its
submodules.
Finishes rdar://problem/26880017.
Remove the diagnostic that warns when an availability check is unnecessary
because the minimum deployment target ensures it will always be true. This
diagnostic is valuable (it tells users that they have dead fallback code) but
can also be super annoying when a source file is shared between projects with
different deployment targets. There is not currently a good mechanism to
suppress these warnings (for example, by expressing a "compatibility version" in
the source or as a build setting) and so it is better to turn the diagnostic
off.
rdar://problem/22337402
We currently emit diagnostics for references to deprecated and potentially
unavailable APIs in branches that are dead for the current platform and
minimum deployment target. These dead branches can arise when sharing swift
source between targets or in playgrounds intended to be run on multiple OS
versions.
So for example, suppose the developer has the following code targeting
OSX 10.9+ and iOS 8.0+:
if #available(OSX 10.10, *) {
// Use replacement API introduced in OSX 10.10/iOS 8.0
} else {
// Use old API deprecated in OSX 10.10/iOS 8.0
}
Compiling the above for iOS and with a miniminum deployment of 8.0 will
result in a deprecation diagnostic for the use of the API in the else branch
even though that branch will never execute. (Note that the branch is not dead on
the OSX target because the minimum deployment target is 10.9. For OSX we also
won't emit a deprecation warning because the API wasn't deprecated until 10.10.
This commit updates availability checking to create refinement contexts with
empty OS version ranges for #available() else branches when those branches
will definitely not execute. It suppresses deprecation and potential
availability diagnostics within those contexts. It does not suppress diagnostics
for references to APIs annotated as unconditionally unavailable (i.e., with
@available(OSX, unavailable, ...) and friends).
rdar://problem/22307360
Swift SVN r31631
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
We now disregard deprecation warnings if the reference to a deprecated symbol is lexically
contained in a declaration that is itself deprecated on all deployment targets.
Swift SVN r26693
Minor tweaks to availability diagnostic text based on feedback from Chris, Ted, and Doug.
This changees "'foo' is only available on OS X version 10.10 or greater" to
"'foo' is only available on OS X 10.10 or newer".
This change also updates the deprecation and obsoleted diagnostics to be consistent with
the new text.
Swift SVN r26344
This commit suppresses errors for references to unavailable symbols inside
implicit functions.
This is a quick hack to fix a hit-listed radar <rdar://problem/20007266> where
the compiler was emitting spurious errors for enums explicitly marked
unavailable in Objective-C and whose nil literal conformance is synthesized by
the importer. These errors could occur when user code made no apparent reference
to the enum in question and instead only referred to an imported class that
itself referred to the enum in a method signature.
We will need to do something systematic about availability and deprecation
diagnostics in synthesized code. In particular, we should make sure that:
(1) we never emit code that references explicitly unavailable symbols;
(2) that the user never gets an error about symbol that they did not explicitly type; and
(3) that errors can dealt with via the appropriate availability check or annotation. I'm
tracking this with radar rdar://problem/20024980.
rdar://problem/20007266
Swift SVN r26251
This commit suppresses deprecation warnings for references to deprecated symbols
by climbing the DeclContext hierarchy to determine if the warning location is
inside an implicit function.
This is a quick fix to get rid of spurious warnings for deprecated enums whose
nil literal conformance is synthesized by the importer. These warnings would
occur even when user code made no apparent reference to the enum in question and
instead only referred to an imported class that itself referred to the enum in a
method signature. This quick fix intentionally drops some valid warnings
(for example, for a synthesized call to a deprecated initializer in a super
class). rdar://problem/20024980 tracks adding these special purpose warnings
back.
rdar://problem/20007266
Swift SVN r25720
