Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
Generated Swift interfaces for modules with overlays, like Foundation or Dispatch, currently contain `import Foundation`/`import Dispatch` statements.
These imports are redundant, and this change removes them.
The Base class already includes them, so don't duplicate them in its
subclasses. Also stops us including members from extensions of the base class
itself.
Resolves rdar://problem/50960433
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
We would previously hide the protocol, its extensions and members, but the '_'
prefix really just means the protocol itself isn't intended for clients, rather
than its members.
This also adds support for 'fully_annotated_decl' entries in doc-info for
extensions to be consistent with every other decl, and removes the
'fully_annotated_generic_signature' entry we supplied as a fallback.
Also fixes several bugs with the synthesized extensions mechanism:
- The type sustitutions applied to the extension's requirements were computed
using the extension itself as the decl context rather than the extension's
nominal. The meant the extension's requirements themselves were assumed to
hold when determining the substitutions, so equality constraints were always
met. Because of this extension members were incorrectly merged with the base
nominal or its extensions despite having additional constraints.
- Types within the requirements weren't being transformed when printed (e.g.
'Self.Element' was printed rather than 'T') both in the interface output and
in the requirements list. We were also incorrectly printing requirements
that were already satisfied once the base type was subsituted in.
- If both the protocol extension and 'enabling' extension of the base nominal
that added the protocol conformance had conditional requirements, we were
only printing the protocol extension's requirements in the synthesized
extension.
- The USR and annotated decl output embedded in the 'key.doc.full_as_xml'
string for synthesized members were printed to match their original context, rather than
the synthesized one.
Resolves rdar://problem/57121937
This attribute is intended to mean there's a replacement declaration that
should be used instead in Swift code. We already filter out decls with this
attribute in code completion, but were still exposing them in generated
interfaces.
Resolves rdar://problem/62464954
Out handling of clang submodules was handled differently between DocInfo and
InterfaceGen. For InterfaceGen submodules were mapped back to their top-level
clang modules (or their Swift overlay if it had one) before being passed
into printSubmoduleInterface, along with the dot separated name of the submodule.
For DocInfo, they were not, and only the rightmost component of their name was
passed. The call to retrieve the decls from a ModuleDecl doesn't work if the
ModuleDecl wraps a clang submodule, so we were missing these decls.
InterfaceGen for submodules also shouldn't have been mapping the module back to
the overlay of top-level clang module, as that meant we ended up printing
import decls from the Swift overlay in the submodule's interface.
Resolves rdar://problem/57338105
It's treated as a keyword by syntactic highlighting, but wasn't annotated as a
keyword by code completion, cursor info, or doc info.
Resolves rdar://problem/61114942
We weren't handling this case, so their generated interfaces / doc info
wouldn't include symbols from the cross-import overlays, and we wouldn't
map the underscored cross-import overlay name back to the declaring
framework's name in cusor-info, completion results or when indexing.
Resolves rdar://problem/62138551
We previously didn't report the requirements in the where clause of 'boxes'
below because it didn't have generic parameters of its own:
public struct Box<Wrapped> {
public func boxes() -> [Box<Wrapped.Element>] where Wrapped: Sequence { fatalError() }
}
Resolves rdar://problem/60658263
This adjusts the tests for the difference between line endings on
different platforms. Windows uses CRLF while most Unicies use LF. This
was exposed during the update to the new LLVM snapshot.
When sanitizing the documentation comments for synthesized extensions,
we expect some text like "<declaration>extension". This isn't the case
when use-facing attributes are present.
rdar://50913510
Otherwise we can get in trouble when a local type is named, say,
'Sequence'.
Also contains test updates and a fix for Harlan's previous commit,
which actually affects all typealiases, not just those in the Builtin
module.
* Add swift_evolve feature and disable several tests
This change adds a swift_evolve feature to our lit configuration and uses it to mark several tests as unsupported by swift_evolve.
One of these—test/api-digester/stability-stdlib-abi.swift—is actually pretty bad; we would really like to have it. But the digester has known issues exposed by swift-evolve.
* Remove order dependency in another test
* Tweaks from Jordan’s review
* Distinguish between tests which are intentionally unsupported and temporarily disabled.
* Add an explanation for one unsupproted test.
* Code nitpick.
* 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
We were redundantly printing constraints that were implied by the base
type (the type being extended). Rather than special-casing constraints
on a protocol's 'Self' type, omit any requirements that are already
satisfied by the extended type instead.
https://bugs.swift.org/browse/SR-7413
