Commit Graph

269 Commits

Author SHA1 Message Date
Doug Gregor
ebdfb40ebb [SE-0160] Allow one to enable/disable Swift 3 @objc inference rules.
Introduce flags `-enable-swift3-objc-inference` and
`-disable-swift3-objc-inference` to enable/disable the Swift 3 `@objc`
inference rules. Under `-swift-version 3`, default to the former;
under `-swift-version 4`, default to the latter. For testing purposes,
one can provide either flag in eiher language mode.
2017-03-31 21:22:16 -07:00
Brian King
29c1fc472b Generate an error message on protocol extensions with the final attribute. 2017-03-09 14:18:39 -05:00
Rintaro Ishizaki
b69aa96a73 [QoI] Improve diagnostics for non-representable-in-objc types
On:
  @objc let foo = SwiftStruct()

Previously:
  <unknown>:0: note: Swift structs cannot be represented in Objective-C
Now:
2017-02-01 14:41:39 +09:00
Slava Pestov
02f6bdefaa Sema: Fix crash if explicit @objc with a name is put on a deinitializer
It would be better to just ban @objc on deinit altogether, but it
was accepted in Swift 3.0.
2017-01-28 18:35:25 -08:00
Joe Groff
fb4a769f05 Sema: Warn when Swift classes attempt to implement ObjC +initialize.
Swift's language model doesn't guarantee that type metadata will ever really be used, which makes overriding initialize() error-prone and not really any better than manually invoking an initialization function. Warn about this for Swift 3 compatibility and reject attempts to override +initialize in Swift 4.
2017-01-17 15:06:44 -08:00
Slava Pestov
2c7aae4128 Sema: 'Never'-returning functions can be represented in Objective-C
Fixes <https://bugs.swift.org/browse/SR-3203>.
2017-01-03 20:13:42 -08:00
Slava Pestov
f130bb1975 Sema: Fix recent regression where generic parameters were considered to be representable in @objc
This would cause IRGen crashes since it had no way to emit type metadata
in this case.

Fixes <rdar://problem/29782437>.
2017-01-03 15:37:53 -08:00
Slava Pestov
f0f1c60a53 Sema: Fix crash with invalid @objc operators
The corner case of all corner cases.
2016-12-21 14:20:27 -05:00
David Farler
b7d17b25ba Rename -parse flag to -typecheck
A parse-only option is needed for parse performance tracking and the
current option also includes semantic analysis.
2016-11-28 10:50:55 -08:00
Slava Pestov
a760186505 AST: Remove -enable-experimental-nested-generic-types flag 2016-11-18 00:39:15 -08:00
Slava Pestov
cfe9e6a3de IDE: Use GenericSignatures and interface types (mostly)
There was a ton of complicated logic here to work around
two problems:

- Same-type constraints were not represented properly in
  RequirementReprs, requiring us to store them in strong form
  and parse them out when printing type interfaces.

- The TypeBase::getAllGenericArgs() method did not do the
  right thing for members of protocols and protocol extensions,
  and so instead of simple calls to Type::subst(), we had
  an elaborate 'ArchetypeTransformer' abstraction repeated
  in two places.

Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.

This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.

We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
2016-10-02 23:49:15 -04:00
Michael Ilseman
8923a12585 [ASTPrinter] Switch to new ParameterTypeFlags
Switch printing off of using Function's ExtInfo for autoclosure and
escaping, and onto the ParameterTypeFlags, which let us do precise and
accurate context-sensitive printing of these parameter type
attributes. This fixes a huge list of issues where we were printing
@escaping for things like optional ObjC completion handlers, among
many others. We now correctly print @escaping in more places, and
don't print it when it's not correct.

Also updates the dumper to be consistent and give a good view of the
AST as represented in memory. Tests updated, more involved testing
coming soon.
2016-09-22 12:24:02 -07:00
Doug Gregor
4820453820 [Type checker] Minor cleanups for @objc inference from witnesses. 2016-09-06 20:59:57 -07:00
Doug Gregor
cba7eb960d [Type checker] Throwing methods must return an object type in the @objc thunk to be @objc.
A throwing method can only be exposed to Objective-C if we can map the
return type convention, either because the return type is Void or
because it is something that is bridged to an object type (and can
therefore be nil to indicate error). Our predicate for checking
"bridged to an object type" didn't account for value types that are
exposed to (or come from) C, and therefore aren't actually bridged to
object types in the Objective-C thunk, meaning they cannot be
optional. An existing hack dealt with the largest class of
these---types like Int and Bool that can be dynamically bridged
to NSNumber---but generalize this by checking exactly how the result
type is going to be represented in Objective-C, rejecting '@objc' for
cases where the result type won't be an object type.

Fixes rdar://problem/28035614 for real.
2016-09-06 16:25:46 -07:00
Doug Gregor
7e3c13cb27 [Type checker] Infer @objc for witnesses of protocol conformances from superclasses.
Extend @objc inference for witnesses to also consider optional
protocols whose conformances come from superclasses. Because we don't
do real binding of witnesses for inherited conformances, this is a bit
of an heuristic, looking at whether the witness is a potential match
(vs. the known exact match), so it can infer @objc somewhat more
liberally than a complete solution.

Fixes rdar://problem/27348369.
2016-09-06 15:31:57 -07:00
Doug Gregor
7e2efe5591 [Type checker] Infer @objc for protocol conformances in other extensions.
Expand the scope of @objc inference for witnesses to encompass
witnesses that are in a different extension from that of the
conformance, including cases where one or the other is in the nominal
type declaration itself.

Fixes rdar://problem/26892526.
2016-09-06 13:04:00 -07:00
Jordan Rose
4372a30147 Operator methods are not @objc-compatible. (#4430)
https://bugs.swift.org/browse/SR-2419
2016-08-23 13:36:56 -07:00
Jordan Rose
c8fbfb782e Merge pull request #4029 from aleksgapp/bugfix/SR-1894
[SR-1894] Consider protocol metatypes as not @objc compatible.
2016-08-12 17:42:01 -07:00
Dmitri Gribenko
d175b3b66d Migrate FileCheck to %FileCheck in tests 2016-08-10 23:52:02 -07:00
Slava Pestov
0004bc480a IRGen: Differentiate between Swift.Bool and ObjCBool
SIL already does this where necessary, except with foreign throwing
functions; this patch changes Sema and the ClangImporter to give
them an ObjCBool foreign error result type explicitly.

This fixes a problem where calls to functions taking and returning
the C99 _Bool type were miscompiled on Mac OS X x86-64, because
IRGen was conflating the Objective-C BOOL type (which is a signed
char on some platforms) and C99 _Bool (which lowers as the LLVM
i1 type).

Fixes <rdar://problem/26506458> and <rdar://problem/27365520>.
2016-08-10 10:34:24 -07:00
Aleksey Gaponov
9a87f8d855 [SR-1894] Consider metatype of any existential type as not @objc representable. 2016-08-08 13:36:16 +02:00
Doug Gregor
212ffadf5e Improve diagnostic for Error compositions not being representable in Objective-C.
Thanks, Jordan!
2016-08-02 10:21:01 -07:00
Doug Gregor
6575877124 [@objc checking] Only 'Error' is representable in Objective-C (as 'NSError').
Don't allow types conforming to 'Error' or protocol compositions
involving 'Error' to be reflected in Objective-C. We still allow
bridging conversions, but they are not statically bridged. Fixes
SR-2249/rdar://problem/27658940.
2016-08-02 10:13:54 -07:00
Michael Ilseman
c37751ae96 [noescape by defaul] make noescape the default
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.

Adds contentual printing, and updates the test cases.

There is some further (non-source-breaking) work to be done for
SE-0103:

- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
2016-07-29 13:49:08 -07:00
Andrew Trick
a18d490d6a Migrate from UnsafePointer<Void> to UnsafeRawPointer. (#3773)
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.

As proposed in SE-0107: UnsafeRawPointer.

`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.

Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.

* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.

This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.

* Fix a bunch of test cases for Void->Raw migration.

* qsort takes IUO values

* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.

* Parse #dsohandle as UnsafeMutableRawPointer

* Update a bunch of test cases for Void->Raw migration.

* Trivial fix for the SceneKit test case.

* Add an UnsafeRawPointer self initializer.

This is unfortunately necessary for assignment between types imported from C.

* Tiny simplification of the initializer.
2016-07-26 14:21:15 -07:00
Andrew Trick
0ed9ee8dee Revert "Migrate from UnsafePointer<Void> to UnsafeRawPointer. (#3724)"
This reverts commit ece0951924.

This results in lldb failues on linux that I can't readily debug.
Backing out until they can be resolved.
2016-07-26 02:50:57 -07:00
Andrew Trick
ece0951924 Migrate from UnsafePointer<Void> to UnsafeRawPointer. (#3724)
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.

As proposed in SE-0107: UnsafeRawPointer.

`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.

Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.

* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.

This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.

* Fix a bunch of test cases for Void->Raw migration.

* qsort takes IUO values

* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.

* Parse #dsohandle as UnsafeMutableRawPointer

* Update a bunch of test cases for Void->Raw migration.

* Trivial fix for the SceneKit test case.

* Add an UnsafeRawPointer self initializer.

This is unfortunately necessary for assignment between types imported from C.

* Tiny simplification of the initializer.
2016-07-26 02:18:21 -07:00
Joe Groff
d2e1c4a662 Update PrintAsObjC, NameBinding, attr, decl, expr tests for id-as-Any. 2016-07-25 06:40:35 -07:00
Doug Gregor
0eaa5763e4 Minor fixes for SE-0095 2016-07-19 12:01:37 -07:00
Joe
3938d5682a [SE-0095] [Runtime], [Demangler], & AST printer updated to new composition syntax
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
    - “protocol<>” is now “swift.Any”
    - “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
2016-07-19 12:01:37 -07:00
Joe
a6dad0091b [SE-0095] Initial parsing implementation for '&' composition syntax
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’

- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
2016-07-19 12:01:02 -07:00
Slava Pestov
7814c47b71 AST: Slightly change meaning of NominalTypeDecl::getDeclaredType()
Consider this code:

struct A<T> {
  struct B {}
  struct C<U> {}
}

Previously:

- getDeclaredType() of 'A.B' would give 'A<T>.B'
- getDeclaredTypeInContext() of 'A.B' would give 'A<T>.B'

- getDeclaredType() of 'A.C' would give 'A<T>.C'
- getDeclaredTypeInContext() of 'A.C' would give 'A<T>.C<U>'

This was causing problems for nested generics. Now, with this change,

- getDeclaredType() of 'A.B' gives 'A.B' (*)
- getDeclaredTypeInContext() of 'A.B' gives 'A<T>.B'
- getDeclaredType() of 'A.C' gives 'A.C' (*)
- getDeclaredTypeInContext() of 'A.C' gives 'A<T>.C<U>'

(Differences marked with (*)).

Also, this change makes these accessors fully lazy. Previously,
only getDeclaredTypeInContext() and getDeclaredIterfaceType()
were lazy, whereas getDeclaredType() was built from validateDecl().

Fix a few spots where the return value wasn't being checked
properly.

These functions return ErrorType if a circularity was detected via
the generic parameter list, or if the extension did not resolve.
They return Type() if the extension cannot be resolved *yet*.

This is pretty subtle, and I'll need to do another pass over
callers of these functions at some point. Many of them should be
moved over to use getSelfInContext(), getSelfOfContext() and
getSelfInterfaceType() instead.

Finally, this patch consolidates logic for diagnosting invalid
nesting of types.

The parser had some code for protocols in bad places and bad things
inside protocols, and Sema had several different bail-outs for
bad things in protocols, nested generic types, and stuff nested
inside protocol extensions.

Combine all of these into a single set of checks in Sema. Note
that we no longer give up early if we find invalid nesting.
Leaving decls unvalidated and un-type-checked only leads to
further problems. Now that all the preliminary crap has been
fixed, we can go ahead and start validating these funny nested
decls, actually fixing some crashers in the process.
2016-06-18 17:15:24 -07:00
Mishal Shah
87b7bcfd3e Update master to build with Xcode 8 beta 1, OS X 10.12, iOS 10, tvOS 10, and watchOS 3 SDKs. 2016-06-14 14:53:55 -07:00
Doug Gregor
381a12d557 [Sema] @IBAction implies @objc.
Per the core team discussion, @IBAction is tied to the Objective-C
runtime and should imply @objc. This was an oversight when the
attribute was added pre-1.0. Fixes rdar://problem/24750631.
2016-05-24 22:04:49 -07:00
Jordan Rose
670f7b5b6d Optionals of imported value types are not @objc.
While we could bridge 'NSRange' to 'NSRange' and 'NSRange?' to
'NSValue * _Nullable', that (a) would be confusing, and (b) isn't
actually implemented at the moment. Fix my mistake in 477933b to
start accepting these.
2016-05-11 16:18:24 -07:00
Jordan Rose
477933be1d Fix @objc checking for optional value types.
We previously treated 'NSFoo?' as ObjC-compatible simply because 'NSFoo'
was an imported type or was marked '@objc'.
2016-05-09 19:44:55 -07:00
Doug Gregor
c808b00314 Merge pull request #2423 from koke/sr-1395
SE-0070: Make Optional Requirements Objective-C-only.
2016-05-07 20:27:32 -07:00
Jorge Bernal
0a3f913b20 SE-0070: Make Optional Requirements Objective-C-only.
Optional protocol requirements now require an explicit @objc attribute.

Fixes SR-1395
2016-05-06 11:05:52 +02:00
Chris Lattner
2c81c8a114 add some parens to the testsuite, NFC. 2016-05-05 23:19:08 -07:00
Chris Willmore
af0c7bd620 Initial implementation of SE-0054 "Abolish IUO Type" (#2322)
This is a squash of the following commits:

* [SE-0054] Import function pointer arg, return types, typedefs as optional

IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.

* [SE-0054] Only allow IUOs in function arg and result type.

When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.

* [SE-0054] Disable inference of IUOs by default

When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.

* [SE-0054] Remove the -disable-infer-iuos flag.

* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
2016-05-03 14:06:19 -07:00
Doug Gregor
622f49cfec [Conformance checking] Cleanup renaming check, fix a test. 2016-04-22 15:01:59 -07:00
Doug Gregor
f6835ec42d [Protocol conformance] Simplify/unify checking for @objc/non-@objc conflicts.
When a non-@objc witness matches an @objc requirement except for
@objc-ness, treat it the same way whether it's an optional requirement
or not, except that it's a warning for the optional case. Should
finish off rdar://problem/25159872.
2016-04-20 16:41:44 -07:00
Chris Lattner
b5828e6a61 Port over all the semantic checking for @noescape/@autoclosure from the
declattr path to the typeattr path.  The decl attr path will eventually
go away, but we need to keep it for now to support the legacy syntax
migration.
2016-04-15 14:16:43 -07:00
Jordan Rose
bc83940301 Make pointer nullability explicit using Optional.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md

- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
  hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
  (like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
  optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
  parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.

I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)

The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
2016-04-11 20:06:38 -07:00
Manav Gabhawala
7928140f79 [SE-0046] Implements consistent function parameter labels by discarding extraneous parameter names and adding _ where necessary 2016-04-06 20:21:58 -04:00
practicalswift
798877ae77 [gardening] "if (foo)[SPACE][SPACE]{" → "if (foo)[SPACE]{" 2016-04-03 22:57:05 +02:00
Doug Gregor
86b7322e87 [Sema -> AST] Refactor "is representable in Objective-C?" checking.
Migrate the check for whether a given type is representable in
Objective-C, which is currently used to verify when @objc can be
inferred or verify that an explicitly-written @objc is well-formed,
from Sema into a set of queries on the Type within the AST library, so
it can be used in other parts of the compiler.

As part of this refactoring, clean up and improve a number of aspects
of this code:

* Unify the "trivially representable" and "representable" code paths
  into a single code path that covers these cases. Clarify the
  different levels of "representable" we have in both the code and
  in comments.

* Distinguish between representation in C vs. representation in
  Objective-C. While we aren't using this now, I'm anticipating it
  being useful to allow exporting C interfaces via @_cdecl (or
  similar).

* Eliminate the special cases for bridging String/Array/Dictionary/Set
  with their Foundation counterparts; we now consult
  _ObjectiveCBridgeable conformances exclusively to get this
  information.

* Cache foreign-representation information on the ASTContext in a
  manner that will let us more easily get the right answer across
  different contexts while providing more sharing than the TypeChecker
  version.

Annoyingly, this only seemed to fix a small class of error where we
were permitting Unsafe(Mutable)Pointer<T> to be representable in
Objective-C when T was representable but not trivially representable,
e.g., T=String or T=AnyObject.Type.
2016-03-16 23:53:48 -07:00
Max Moiseev
fcad164e18 Merge remote-tracking branch 'origin/master' into swift-3-api-guidelines 2016-02-22 12:59:57 -08:00
Joe Groff
26e55ce465 Sema: Initial parsing and synthesis for properties with behaviors.
Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:

  ```
  protocol behavior {
    associatedtype Value
  }
  extension behavior {
    var value: Value { ... }
  }
  ```

then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:

  ```
  struct Foo {
    var [behavior] foo: Int
  }

  /* behaves like */

  extension Foo: private behavior {
    @implements(behavior.Value)
    private typealias `[behavior].Value` = Int

    var foo: Int {
      get { return value }
      set { value = newValue }
    }
  }
  ```

If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:

  ```
  protocol storageBehavior {
    associatedtype Value

    var storage: Something<Value> { ... }
  }
  extension storageBehavior {
    var value: Value { ... }

    static func initStorage() -> Something<Value> { ... }
  }
  ```

then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:

  ```
  struct Foo {
    var [storageBehavior] foo: Int
  }

  /* behaves like */

  extension Foo: private storageBehavior {
    @implements(storageBehavior.Value)
    private typealias `[storageBehavior].Value` = Int
    @implements(storageBehavior.storage)
    private var `[storageBehavior].storage`: Something<Int> = initStorage()

    var foo: Int {
      get { return value }
      set { value = newValue }
    }
  }
  ```

In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.

Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
2016-02-20 15:01:05 -08:00
Dmitri Gribenko
dd75aed67a Merge remote-tracking branch 'origin/master' into swift-3-api-guidelines 2016-02-17 14:40:05 -08:00