Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10506] Formalize getType closure pattern #52906

Open
beccadax opened this issue Apr 18, 2019 · 1 comment
Open

[SR-10506] Formalize getType closure pattern #52906

beccadax opened this issue Apr 18, 2019 · 1 comment
Labels
compiler The Swift compiler in itself good first issue Good for newcomers task type checker Area → compiler: Semantic analysis

Comments

@beccadax
Copy link
Contributor

Previous ID SR-10506
Radar None
Original Reporter @beccadax
Type Task
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Task, StarterBug, TypeChecker
Assignee None
Priority Medium

md5: dd815550dade98eb89026bfbc9fc1d2f

Issue Description:

Various methods in the compiler from swiftAST up take one or more closure parameters which are used to override how the types of AST nodes (mainly expressions) are accessed. In practice, these are mainly used to make a function look up types in a ConstraintSystem during type checking instead of using the values in the nodes themselves. A non-exhaustive list of examples:

  • AbstractClosureExpr::getResultType() and CallExpr::create() take a "getType" closure.

  • TypeExpr::getInstanceType() takes two closures for "hasType" and "getType".

  • LiteralExpr::shallowClone() takes two closures for "getType" and "setType".

  • Expr::dump() takes three closures for "getType", "getTypeOfTypeLoc", and "getTypeOfKeyPathComponent". These are plumbed through to various internal types in ASTDumper.cpp.

Rather than continuing to pass around ad-hoc closures, we should formalize this interface into a class that we can pass around. For example, we might declare an "ExprTypeMap" class in AST which declares all of the hasType()/getType()/setType() methods from ConstraintSystem and simply calls through to the equivalent methods on the AST nodes; then we can have ConstraintSystem inherit from this class and override these methods.

@slavapestov
Copy link
Member

I like the idea of defining a data type in lib/AST/ that stores an expression type map. In fact, Expr::getType() doesn’t need to exist at all; CSApply can walk the type map given to it by the solver and simplify each type to eliminate variables, and SILGen can simply read from this map when generating SIL from expressions.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself good first issue Good for newcomers task type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

2 participants