Skip to content

[ASTPrinter] Print expressions #40691

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

Merged
merged 5 commits into from
Jan 12, 2022
Merged

[ASTPrinter] Print expressions #40691

merged 5 commits into from
Jan 12, 2022

Conversation

louisdh
Copy link
Contributor

@louisdh louisdh commented Dec 22, 2021

Add new -print-ast-decl frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.

The existing -print-ast option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.

Printer << " ";
visit(stmt->getBody());
}

void PrintAST::visitRepeatWhileStmt(RepeatWhileStmt *stmt) {
Printer << tok::kw_do << " ";
Printer << tok::kw_repeat << " ";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do while has been renamed to repeat while for a few years now... 🙂

@@ -1,4 +1,4 @@
// RUN: %target-swift-frontend -print-ast %s 2>&1 | %FileCheck %s
// RUN: %target-swift-frontend -print-ast-decl %s 2>&1 | %FileCheck %s
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be useful to add tests for the synthesized bodies for Equatable/Hashable/etc. But this existing test just wants to check the access level. Using the new -print-ast-decl makes this the least disruptive.

Copy link
Contributor

@hamishknight hamishknight left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see this being added! I have some more comments, but otherwise this LGTM

Comment on lines +4456 to +4469
void PrintAST::visitUnresolvedSpecializeExpr(UnresolvedSpecializeExpr *expr) {
visit(expr->getSubExpr());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we print the generic arguments here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find an example where this expression is created.

Generally, I'd like to merge this even if some expressions aren't printed 100% correct yet (there certainly are more parts missing).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's created by the parser for e.g Array<Int>, before the types have been resolved. It gets rewritten by the type-checker though, so I don't believe the current frontend printing option will come across it. But if we ever wanted to print the AST prior to type-checking, I think we should print the generic arguments. But yeah, that doesn't need to hold up this PR.

Copy link
Contributor

@hamishknight hamishknight left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of extra comments, but I'm happy for them to be done in a follow-up

Comment on lines +22 to +23
// CHECK: @_hasInitialValue private let conditional: Archivable? = a as? Archivable
// CHECK: @_hasInitialValue private let forced: Archivable = a as! Archivable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'll want to print access modifiers here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's really only used for debugging right now. If this was to be presented to a user, we'd want to filter this so it becomes:

let conditional = a as? Archivable

(removing @_hasInitialValue private and the explicit type annotation, if possible)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right yeah, my main concern was just that e.g:

func foo() {
  private let x = 0
}

isn't valid code

_ = test(payload: payload)
}
// CHECK-LABEL: internal func process(payload: Payload) {
// CHECK-LABEL: if .empty = payload {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the case keyword was dropped here

@hamishknight
Copy link
Contributor

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 4a797ee50aaf7b5c5e8cf71308f79b2332e3cf74

Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.

The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
@louisdh
Copy link
Contributor Author

louisdh commented Jan 11, 2022

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 13807f2

@louisdh
Copy link
Contributor Author

louisdh commented Jan 12, 2022

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants