Commit Graph

6 Commits

Author SHA1 Message Date
Allan Shortlidge
b6ee0796c8 AST: Type-check @available attributes before synthesizing CaseIterable.
An `AvailableAttr` written in source with an unrecognized availability domain
is now only marked invalid after type-checking the attribute. This resulted in a
regression where `CaseIterable` synthesis was blocked incorrectly under the
following very narrow circumstances:

1. Every `@available` attribute on the elements of the enum is invalid.
2. The module is being emitted and lazy type-checking is enabled.
3. The enum is public and the only top-level declaration in the file.

Type-checking the attribute was delayed just enough that it would not be
considered invalid by the type the `CaseIterable` conformance was being
synthesized, resulting in a spurious error.

There were zero tests exercising `CaseIterable` synthesis for enums with
elements that have availability requirements, so I added some.

Resolves rdar://144897917.
2025-02-16 12:20:48 -08:00
Robert Widmann
75207cbe23 Allow Deriving Type Witnesses Across Files
A recent change to witness matching in #32578 suddenly made the
following construction illegal:

// File1.swift
enum MyEnumInAnotherFile { /**/ }

// File2.swift
extension MyEnumInAnotherFile {
  static var allCases: [MyEnumInAnotherFile] { /**/ }
}

Because it was no longer possible to derive the type witness for
`AllCases`. This is because, when inference ran before synthesis, we
would use the value witness to pick out the type witness and thus had no
need for synthesis. Now that we run synthesis first, we ought to just
allow deriving type witnesses across files, but still ban deriving value
witnesses. In general, if you can utter a type in a different file to
extend it, you should be able to see the requirements necessary to
derive a default type witness.

rdar://66279278, rdar://66279375, rdar://66279384, rdar://66279415, rdar://66279503
2020-07-29 12:10:26 -07:00
Huon Wilson
80a74b4dfc [AST] Choose an implied conformance source next to the type, if possible.
If a conformance to a protocol is implied by several other
conformances (i.e. protocol P: Equatable {} and protocol Q: Equatable {} and a
type declares conformance to both P and Q), we should choose a source that's in
the same file as the type, if we can, because automatic synthesis of
conformances (for Equatable, Hashable, etc.) only works in that case.

Fixes rdar://problem/41852654.
2018-07-06 18:24:21 +10:00
Huon Wilson
47e643af0e [Sema] Fix synthesis of Equatable and Hashable conformances in extensions of generic types.
https://bugs.swift.org/browse/SR-6803
2018-05-07 09:41:25 +10:00
Huon Wilson
3488a3a53b [Sema] Allow synthesis of protocol conformances in extensions.
This works for all protocols except for Decodable on non-final classes, because
the init requirement has to be 'required' and thus in the type's declaration.

Fixes most of https://bugs.swift.org/browse/SR-6803.
2018-05-07 09:41:25 +10:00
Robert Widmann
dac06898e9 [SE-0194] Deriving Collections of Enum Cases
Implements the minimum specified by the SE-proposal.

* Add the CaseIterable protocol with AllCases associatedtype and
allCases requirement
* Automatic synthesis occurs for "simple" enums
    - Caveat: Availability attributes suppress synthesis.  This can be
              lifted in the future
    - Caveat: Conformance must be stated on the original type
              declaration (just like synthesizing Equatable/Hashable)
    - Caveat: Synthesis generates an [T].  A more efficient collection
              - possibly even a lazy one - should be put here.
2018-03-09 00:22:55 -05:00