Witness matching is a source of a lot of ad-hoc cycles, and mixes the
logic that performs resolution, caching, validation, and cycle detection into one
place. To make matters worse, some checkers kick off other checks in
order to cache work for further declarations, and access an internal
cache on their subject conformance for many requirements at once, or
sometimes just one requirement.
None of this fits into the request evaluator's central view of the
caching. This is further evidenced by the fact that if you attempt to
move the caching step into the evaluator, it overcaches the same
witness and trips asserts.
As a start, define requests for the resolution steps, and flush some
hacks around forcing witness resolution. The caching logic is mostly
untouched (the requests don't actually cache anything), but some cycle
breaking is now handled in the evaluator itself. Once witness matching
has been refactored to cache with the evaluator, all of these hacks can
go away.
My urge to destroy the LazyResolver outweighs the compromises here.
After converting a function type to its corresponding SIL type by our usual rules, extract
the substituted generic signature and common interface type for all concrete function types
that the function could be called as. We don't currently have any use cases for distinguishing
types at finer granularity than generic class-constrained/generic unconstrained/not-generic, so
to reduce the amount of conversion noise in SIL, generate the most general generic signature
possible, by extracting every position with a dependent generic parameter or associated type thereof
into a separate generic parameter in the substituted signature, discarding all constraints except
for `AnyObject` layout constraints. This way, if `foo<T>(x: (T, T) -> ())` calls
`bar<T, U>(x: (T, U) -> ())` and forwards `x` along, the two closures that only vary in genericity
don't need a conversion even with substituted function types, because they'll both have the same
abstract lowering `<A, B> (A, B) -> ()` with different substitutions.
Codable's deep magic currently forces conformance checks in the middle
of name lookup in order to inject CodingKeys into lookup results. This
is compounded by the fact that this lookup fixup is occuring
incrementally, meaning depending on order of requirements being looked
up, Decl::getMembers() will give you a different answer.
Compounding this, NameLookup relied on the LazyResolver to formalize
this layering violation, and relied on implicit laziness to guard
against re-entrancy.
The approach is multi-pronged:
1) Shift the layering violation into the request evaluator
2) Spell out the kinds of resolution we support explicitly (make them
easier to find and kill)
3) Remove the LazyResolver entrypoint this was relying on
4) Split off the property wrappers part into its own utility
Adds parsing for a type attribute `@differentiable`, which is optionally allowed to have argument `@differentiable(linear)`.
The typechecker currently rejects all uses of `@differentiable` with "error: attribute does not apply to type". Future work (https://bugs.swift.org/browse/TF-871https://bugs.swift.org/browse/TF-873) will update the typechecker to allow this attribute in places where it is allowed.
Resolves https://bugs.swift.org/browse/TF-822.
These include memberwise initializers for pointer properties and enum
case constructors for pointer payloads. In both cases, the pointer is
being immediately escaped, so don't allow the user to pass a temporary
pointer value.
Diagnose ephemeral conversions that are passed to @_nonEphemeral
parameters. Currently, this defaults to a warning with a frontend flag
to upgrade to an error. Hopefully this will become an error by default
in a future language version.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
Convenience inits are only allowed on classes and in extensions thereof. And in CFTypes we are not allowed to put convenince inits since swift does not support this feature yet.
This PR solve the bad fix suggestion when a user declare a init method in an extension of CF Type.
Another bug (similar to this one) that i found and became visible when i was doing the test cases for SR-116779 was the fact that if you declare a convenience init that delegates the init function in self, a fix suggestion will appear. The same suggestion that is causing troubles in SR-11679. The fix for this was removing the fix suggestion when the class kind type was CFType since if we leave it as is, it will be the same problem as SR-11679.
SR-11679: PR Feedback
Formatting the new code with clang-format and using `isa` and `cast` instead of `dyn_cast`
SR-11679: PR Feedback
Inlining `cast
SR-11679: PR Feedback
Remove semi-colon
SR-11679: PR Feedback
Remove empty line & add mark to avoid fixit.
SR-11679: PR Feedback
Remove empty line.
SR-11679: PR Feedback
Move Diagnostics Info & Remove empty lines
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
This option is useful to debug the compiler itself, to simulate debug info as it
would be generated when producing optimized code, but without the unpredictable
output of an optimizing debugger.
* [Sema] Factor out shouldAttemptInitializerSynthesis
This makes sure we don't attempt to synthesize
a memberwise or default initializer for an invalid
decl, or one in a module interface.
* [Sema] Requesify inheritsSuperclassInitializers
This commit introduces a request for computing
whether a class inherits both designated and
convenience initializers from its superclass.
The shared logic of finding initializers which the
subclass hasn't overriden has been factored out
into `collectNonOveriddenSuperclassInits`.
* Cleanup addImplicitInheritedConstructorsToClass
This commit removes some code that's no longer
needed. In addition, now that we've requestified
`inheritsSuperclassInitializers`, we can directly
diagnose on non-inherited required convenience
inits within the loop.
* Inherited init synthesis no longer deals with clang decls
Now that the computation of
`inheritsSuperclassInitializers` has been split off
into a request, we can avoid calling
`addImplicitInheritedConstructorsToClass` for clang
decls.
* Address review feedback
Continue to cache the InheritsSuperclassInits bit
on the AST.
