Files
swift-mirror/test/PrintAsObjC/Inputs/circularity.h
Jordan Rose 8282160de8 [PrintAsObjC] Handle circularities introduced by ObjC generics.
Like Swift generics, Objective-C generics may have constraints; unlike
Swift generics, Objective-C doesn't do separate parsing and
type-checking passes. This means that any generic arguments for
constrained generic parameters must be fully-defined, in order to
check that they satisfy the constraints.

This commit addresses this problem with three different mechanisms,
one for each kind of declaration that might run into this issue:

- For classes, if a member references a type with constrained generic
  parameter, and the corresponding argument type hasn't been printed
  yet, that member is "delayed", which means it is put into a category
  at the end of the file.

- Protocols cannot have categories, so for protocols we instead see if
  we can print the definition of the other type first. To break
  circular dependencies, the printer will not attempt this if both the
  type and the protocol are already being depended on. This isn't
  perfect (see below).

- Rather than delaying members of extensions, we just delay them
  wholesale. This keeps related members together, but also has
  problems (see below).

These approaches solve the most common cases while still not crashing
in the uncommon ones. However, there are still a number of problems:

- The protocol heuristic is overly negative, which means we may generate
  an invalid header even when there's a reasonable ordering. For example,
  a single class might inherit from a class A and conform to protocol P,
  and protocol P depends on class A as a generic argument. In this case,
  defining class A first is the right thing to do, but it's possible for
  the printer to decide that there's circularity here and just forward-
  declare A instead.

- Protocols really can be circular. This can be fixed by printing a
  forward-declared protocol alongside the generic constraints, i.e.
  'id <MoreThanNSCopying, NSCopying>' instead of just
  'id <MoreThanNSCopying>'.

- Extensions can introduce protocols as well. This is not modeled at
  all; if a member depends on a protocol conformance, it's assumed
  that simply printing the class would be sufficient. This could be
  fixed by checking how a generic argument satisfies its constraints,
  possibly delaying individual members from extensions in order to
  print them sooner.

- More cases I haven't thought about.

Test cases for some of these problems are in the new
circularity-errors.swift file, mostly to make sure the ObjC printer
doesn't crash when it encounters them.

rdar://problem/27109377
2016-08-09 10:41:09 -07:00

23 lines
403 B
Objective-C

// This file is meant to be used with the mock SDK, not the real one.
#import <Foundation.h>
#define SWIFT_NAME(x) __attribute__((swift_name(#x)))
@protocol Proto
@end
@interface ProtoImpl : NSObject <Proto>
@end
@interface Parent : NSObject
@end
@interface Unconstrained<T> : NSObject
@end
@interface NeedsProto<T: id <Proto>> : NSObject
@end
@interface NeedsParent<T: Parent *> : NSObject
@end