Pushes __consuming through the frontend and extends existing
attribute-based diagnsotics to cover it. Unlike `nonmutating`,
__consuming is allowed in class methods, though it makes little
sense to put it there.
I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
Also, begin to pass around base types instead of raw InOutType types. Ideally, only Sema needs to deal with them, but this means that a bunch of callers need to unwrap any inouts that might still be lying around before forming these types.
Multiple parts of the compiler were slicing, dicing, or just dropping these flags. Because I intend to use them for the new function type representation, I need them to be preserved all across the compiler. As a first pass, this stubs in what will eventually be structural rules as asserts and tracks down all callers of consequence to conform to the new invariants.
This is temporary.
...because they make things harder for people trying to use
Swift.print. Before:
error: 'print' has been renamed to 'printDocument(_:)'
After:
error: use of 'print' nearly matches global function
'print(_:separator:terminator:)' in module 'Swift'
rather than instance method 'print(_:extra:)'
(This actually occurs with AppKit's NSDocument, so it's not just a
hypothetical concern.)
rdar://problem/32839733
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
Not every declaration that's syntactically in an Objective-C container
is a member of that container. Double-check the decl context before
adding it.
This is technically a breaking change in non-asserts builds, because
the struct really could be found via member lookup. But that should
be considered a bug, and I /suspect/ no one is relying on it.
rdar://problem/32451417
Somehow the logic had slipped so that we were basing this decision purely
on the ImportTypeKind and not on whether the broader context is bridgeable.
This was allowing us to use bridged types when e.g. importing the results
and parameters of C function pointer types, which is really bad.
Also, when importing a reference to a typedef of block type, do not use
the typedef in a non-bridgeable context. We import typedefs of block type
as fully-bridged types, but this means that it is invalid to import a type
using the typedef in a context where the original C type must be used.
Similarly, make sure we use a properly-imported underlying type of the
typedef when the typedef itself is unavailable.
Also, extend the special behavior of block typedefs to abstract-function
typedefs, which seems to be consistent with the expected behavior of the
tests.
Finally, I changed importType to take a new Bridgeability enum instead of
a raw canFullyBridgeTypes bool. At the time, I was doing that because I
was going to make it tri-valued; that turned out to be unnecessary, but I
think it's an improvement anyway.
The translation from a bit to the specifiers exposed this instance
in the Clang importer where we hooked up a parameter as mutable
but never reflected that in the interface type.
A future patch requires that this parameter be immutable.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
Previously, the importer queued up conformances to complete once it
was done importing the current batch of declarations. However, if
there was a serialized Swift module that extended an imported type to
add a conformance in exactly the wrong way, the importer could end up
asking for that conformance later---even before the reference to the
imported type was resolved. This led to a crash in the deserializer
"while reading conformance for type X".
Instead of this "pending actions" queue, we can just use the
mechanisms already in place for lazily loading conformances. That way
they'll get filled out on demand, which is better all around anyway.
This does mean putting the requirement signature into the "lazy" part
of the conformance, though.
This does as a side effect mean that /all/ of the witnesses for the
imported conformance may be opaque---that is, they will never be
devirtualized to a particular implementation. However, they previously
would have referred to methods implemented in Objective-C anyway,
which are always dispatched with objc_msgSend. So this should have no
practical effect.
rdar://problem/32346184
Rather than pretend that the requirement signature of a protocol is a
full, well-formed generic signature that one can meaningfully query,
treat it as a flat set of requirements. Nearly all clients already did
this, but make it official. NFC
Ever since we stopped associating the top-level struct of an imported
NS_ERROR_ENUM with the Clang enum declaration, we've been unable to
print imported NS_ERROR_ENUMs. The module-printing infrastructure
would drop them thinking they aren't imported declarations.
This also affected NS_ERROR_ENUMs that were imported as members of
another type, as well as other types imported as members.
Fixes rdar://problem/32497693.
That is, if a member is redeclarable, use the module of the definition
if possible, and the canonical declaration otherwise. This is
consistent with what we do when we actually import the declaration.
Without this, we can end up dropping declarations.
rdar://problem/32816381
In Swift 3 mode, infer @_downgrade_exhaustivity_check for any enum
elements that were introduced in the 2017 SDKs (macOS 10.13, iOS 11.0,
tvOS 11.0, watchOS 4.0). This is a stop-gap until we get "open" enums,
but serves an important source-compatibility use case.
Fixes rdar://problem/32824207.
`ClangImporter`'s `importType` should always return interface types
for everything it imports, which helps to avoid tracking of declaration
contexts and remapping returned types in/out of them.
Resolves: rdar://problem/32298667
Previously, we did not properly handle levels of indirection for
swift_newtype-ed typedefs of pointer types. We imported them in a way
that tried to present the value semantics of the pointee rather than
of the pointer. We then tried (sometimes incorrectly) to detect and
fix this up during SILGen.
Instead, model with the value semantics of the pointer itself. SILGen
can then be simplified to just pass swift_newtypes the same as any
other struct: directly for non-mutating and indirectly for mutating
(i.e. inout self). Tests added.
Method types are now required to be `(Self) -> (Args...) -> Return`, not
`Self -> (Args...) -> Return`.
See also https://github.com/apple/swift/pull/9454 .
Fixes rdar://problem/32588152 .
