Tests importing AppKit have a tendency to be flaky if they share a
module cache with other builds using a different set of framework search
flags. Make sure they use a local cache to avoid picking incompatible
cached modules.
Alternatively, we could align all builds using the same cache to have
exactly the same framework search paths or enable explicit module
builds. I picked the module cache as it's the most reliable solution in
the short and long term.
The 5 tests below import AppKit and have been known to be flaky.
Adapting them to use a custom cache with require more care. For now,
let's use them as control group to validate that the fix works. If these
5 fail without the fixed ones, we should extend the same corresponding
fix to them.
- Interpreter/SDK/GLKit.swift
- Interpreter/SDK/cf_extensions.swift
- Interpreter/SDK/cf_type_bridging.swift
- Interpreter/SDK/mapkit_header_static.swift
- Interpreter/SDK/objc_ns_enum.swift
rdar://142296731
The code that diagnosed availability for types was reverse-engineering
the Type itself, rather than making use of the declaration already
stored within the TypeRepr.
More importantly, it would completely skip nested types, so it would
fail to diagnose a deprecated/unavailable “Bar” in “Foo.Bar”.
Replace the type-inspecting check with a much-simpler walk over the
components of the IdentTypeRepr that looks at the declarations stored
in the IdentTypeRepr directly. This provides proper source-location
information and handles nested types.
This is a source-breaking change for ill-formed Swift 3 code that used
nested type references to refer to something that should be unavailable.
Given that such Swift 3 code was ill-formed, and most uses of it would
crash at runtime, we likely do not need to provide specific logic to
address this in Swift 3 compatibility mode.
...instead of picking one definition arbitrarily. This comes from the
new "lookup table" design in Swift 3---we no longer just look for any
"visible" (imported) macro definition, but instead need to know them
up front. This works fine when there's only one definition per module,
but for modules like 'OpenGL' on macOS, with mutually-exclusive
submodules 'GL' and 'GL3', the compiler was arbitrarily deciding that
all of the macros the submodules had in common belonged to 'GL'.
The new model tries to decide if it's possible for two modules to be
imported separately, and keeps both macro entries if possible, only
deduplicating equivalent definitions at the last minute (when
importing into Swift). This /still/ doesn't perfectly match the
behavior you'd get in C, where a submodule and its parent module could
theoretically have conflicting definitions and you'd be fine as long
as you only imported one of them, but hopefully (a) it's close enough,
and (b) nobody is doing that. (The Swift compiler will prefer the
definition in the parent module even if the submodule is the only one
imported.)
rdar://problem/26731529
Fixes rdar://problem/14776565 (AnyObject lookup for Objective-C
properties with custom getters) and rdar://problem/17184411 (allowing
__attribute__((swift_name("foo"))) to work on anything).
The Swift name lookup tables record name -> declaration mappings
without respect to submodule visibility. When we do name lookup via
those lookup tables, filter out declarations that are not visible.
Note that this implementation is broken in the same way that the
pre-name-lookup-tables implementation is broken, because it uses
Clang's declaration visibility indicators rather than filtering out
based on submodule lookups. We should fix this behavior to provide
proper submodule lookup, but not until after we've matched the
existing behavior with Swift's name lookup tables.
OpenAL.AL is gone.
This module no longer has only explicit submodules, so just remove it.
I'll file a radar to add a synthetic test to fill in the gap since there
are no longer any other modules in the SDK that have this structure.
rdar://21118411
Swift SVN r29077
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
Per Ben's suggestion, use OpenAL as an example of a module with only
explicit submodules. Continue testing OpenGL on OS X since we've gotten
several bugs about it.
Swift SVN r20320
Specifically, handle them by also importing the top-level module. This is
unfortunate, but at least lets people /access/ things in explicit submodules,
even if it doesn't let them limit their import to a specific submodule.
(swift) import OpenGL.GL3
(swift) glGetString
// r0 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
(swift) OpenGL.glGetString
// r1 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
One unfortunate side effect of having a single Clang ASTContext is that if
one Swift module imports a Clang submodule, every Swift module can now see
it. That means /mixing/ incompatible submodules, such as OpenGL.GL and
OpenGL.GL3, still won't work. Filed <rdar://problem/17756745> for that.
<rdar://problem/13140302>
Swift SVN r20288
