A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Get the attribute working for more link entity kinds, which addresses
all the FIXME:s in the original test case.
Now the protocol resilience tests can be updated to use @_weakLinked
for all newly-added protocol requirements and default implementations.
This allows the tests to pass in the backward deployment test scenario
as well.
Eventually this will be based on availability instead of a special
attribute.
This completes <rdar://problem/29888071>.
The former appears in the code base a lot more frequently than the
latter, which returns a GenericTypeParamType *. Use it only in places
where the more specific type is intended.
Avoid triggering the import of all of the members of an Objective-C
class to determine its stored properties, because we don't import
instance variables of Objective-C classes. rdar://problem/45060773
Static properties are not subject to the same restrictions as properties
whose initializers are exposed to clients in @_fixed_layout types.
rdar://45080912
Thanks to @slavapestov for pointing this out! The optimization to avoid
looking through the members of a protocol that can’t possibly have any
associated types was for both deserialized protocols and imported
protocols, but I only supported the former in my previous change. Check
both cases and make the reasons much more obvious.
Also, that change resolved an existing compiler crasher as well.
As an optimization, we don't even look for associated types in @objc
protocols. However, this could lead to broken invariants like "every
associated type has a witness" in ill-formed @objc protocols that do
have associated types.
Implement this optimization by checking whether the protocol has a
Clang node. Fixes rdar://problem/41425828 / SR-8094.
Augment the ASTPrinter to print the name and text of initializer expressions if
a property has an initializer and the type is @_fixed_layout and resides in a resilient module, and serialize the text for partial modules.
With this change, all .swiftinterface files in the project (except for SwiftLang) compile to swiftmodules on macOS.
rdar://43774580
rdar://43812188
- Treat protocol requirements just like associated types in how they
inherit usable-from-inline-ness, rather than special-casing them in
the check for inlinable code.
- Enum elements are already treated this way, so we can remove a
redundant check for that.
- Finally, start enforcing that 'dynamic' declarations need to be
'@usableFromInline' to be used in inlinable functions...in Swift 5
mode or resilient code. I didn't even add a warning in Swift 4/4.2
because it was illegal to use '@usableFromInline' on a 'dynamic'
declaration in Swift 4.2. (Oops.)
These types are all allocated on the ASTContext's BumpPtrAllocator,
and by default their destructors are never called. (ModuleDecl is the
exception; it registers its destructor with the ASTContext on
construction.)
No functionality change.
* [InterfaceGen] Only print 'mutating' and 'nonmutating' on accessors
* Add SILGen test for usage of dynamic accessors in and out of interfaces
* Add -enable-objc-interop to dynamic_accessors test
* Introduce stored inlinable function bodies
* Remove serialization changes
* [InterfaceGen] Print inlinable function bodies
* Clean up a little bit and add test
* Undo changes to InlinableText
* Add serialization and deserialization for inlinable body text
* Allow parser to parse accessor bodies in interfaces
* Fix some tests
* Fix remaining tests
* Add tests for usableFromInline decls
* Add comments
* Clean up function body printing throughout
* Add tests for subscripts
* Remove comment about subscript inlinable text
* Address some comments
* Handle lack of @objc on Linux
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
When we're marking a declaration as @objc and recording it in the
class and source-file lookup tables (for @objc collision detection),
don't cause a cycle by querying `getObjCSelector()`. This is somewhat
of a hack: a better long-term approach would be to move the recording
much later, and request'ify the name computation. That'll be follow-up
work.
Normally we want accessors to perform direct-to-storage access on
their own storage, otherwise we can't ever implement the accessor;
but one special case is the 'modify' coroutine of a 'dynamic'
property, which has to dynamically dispatch to the getter and
setter methods, since they may be replaced at runtime.
First part of <https://bugs.swift.org/browse/SR-8657> /
<rdar://problem/43951732>.
Most callers aren't concerned about the difference between the two (and those that are are already exercising the appropriate assertions with e.g the use of `getFirstType()`).
If we found a declaration in local context, it might be inside a
TopLevelCodeDecl and we're trying to use it from another
TopLevelCodeDecl. In this case, checkAccessUsingAccessScopes() would
produce the wrong result.
I only hit this after removing some hasAccess() checks from code
completion tests.
We should make the isUsableFromInline() query a proper request.
For now though, given a DestructorDecl it has to check the class
itself, because we don't always propagate the @usableFromInline
attribute from the class to the destructor.
* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
