Circular validation cleanups, part 5 #27571
Conversation
slavapestov
force-pushed
the
circular-validation-cleanups-5
branch
3 times, most recently
from
aff611e to
a9e12f7
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
|
@hamishknight is working on a new fix for SR-11085 which should resolve that issue. |
|
@theblixguy @hamishknight That's excellent! It wouldn't be the end of the world if we had to XFAIL that test also, but getting a clean fix in is obviously better. :) |
| @@ -5158,6 +5161,13 @@ class VarDecl : public AbstractStorageDecl { | |||
| } | |||
| }; | |||
|
|
|||
| enum class ParamSpecifier : uint8_t { | |||
There was a problem hiding this comment.
'long as we're here, can we pick a better name than "Specifier"?
There was a problem hiding this comment.
Sure, I'm all ears :) I believe one of your refactorings introduced the name Specifier, but I might be wrong :)
There was a problem hiding this comment.
I did it back then because the it's the name the Swift Book's "grammar" gives it.
slavapestov
force-pushed
the
circular-validation-cleanups-5
branch
2 times, most recently
from
5722126 to
9e30c50
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
|
Unfortunately my idea for fixing SR-11085 didn't quite pan out as well as I was hoping, so feel free to land this with the text XFAIL'ed in the meantime while I try to come up with another fix. |
validateType() is just the TypeLoc-based wrapper; it should not do any checks that resolveType() itself does not do.
Nested types cannot be forward declared which poses difficulties for the request evaluator.
…a request Since getSpecifier() now kicks off a request instead of always returning what was previously set, we can't pass a ParamSpecifier to the ParamDecl constructor anymore. Instead, callers either call setSpecifier() if the ParamDecl is synthesized, or they rely on the request, which can compute the specifier in three specific cases: - Ordinary parsed parameters get their specifier from the TypeRepr. - The 'self' parameter's specifier is based on the self access kind. - Accessor parameters are either the 'newValue' parameter of a setter, or a cloned subscript parameter. For closure parameters with inferred types, we still end up calling setSpecifier() twice, once to set the initial defalut value and a second time when applying the solution in the case that we inferred an 'inout' specifier. In practice this should not be a big problem because expression type checking walks the AST in a pre-determined order anyway.
This eliminates typeCheckParameterList() altogether.
slavapestov
force-pushed
the
circular-validation-cleanups-5
branch
from
9e30c50 to
6701a7e
Compare
|
@swift-ci Please smoke test |
|
@swift-ci please test source compatibility |
Follow-up to #27553.
First, this PR refactors interface type computation for decls with parameter lists (functions, constructors, subscripts, enum elements) so that instead of
validateDecl()setting the interface type of allParamDeclsas a side-effect of validating the parent decl, we now end up callingvalidateDecl()on each individualParamDecl. This completely eliminatestypeCheckParameterList()andvalidateParameterType().Second, the logic that was moved from
validateParameterType()tovalidateDecl()also set theParamDecl's specifier as a side effect. Factor this out into its own request.