Fill out unimplemented expression cases in the ASTPrinter

[hamishknight]

In #40691 we added initial support for printing Expr nodes in the ASTPrinter, and #64667 filled out most of the rest. However there are still some expressions left unimplemented, including:

• All the ImplicitConversionExpr subclasses, we should stamp out their definitions as printing their sub-expression, using a macro
• InterpolatedStringLiteralExpr (this is a tricky case since we'd need to reconstruct the string literal from the TapExpr, or otherwise preserve its original form)

These are partially implemented, with outstanding FIXMEs:

• ClosureExpr
• CaptureListExpr
• KeyPathExpr

Some extras tests would be good for:

• SubscriptExpr (would be great to have a test exercising some other call patterns, e.g multiple arguments, argument labels)
• TupleElementExpr
• ObjCSelectorExpr
• DynamicSubscriptExpr
• EnumIsCaseExpr
• MakeTemporarilyEscapableExpr
• EditorPlaceholderExpr
• DotSyntaxBaseIgnoredExpr

[hamishknight]

cc @louisdh

[jakedves]

Hey, I'm interested in looking at this but I'm not super familiar with the codebase. Do you think this could be an appropriate StarterBug? Thanks

[hamishknight]

Sure, I think this would make a suitable StarterBug, it should give you a good sense of how the AST is structured. I'm happy to be pinged with questions :)

Feel free to pick off individual nodes, though communicate here what nodes you want to take so people don't end up working on the same thing.

[jakedves]

Sure, thanks. I'll ping with any questions I get, and I'll start with IsExpr and ForceValueExpr.

[XaurDesu]

Is there room for another contributor? I could take a look at this if you guys don't mind.

[xedin]

I don’t think anybody is working on this at the moment, so feel free to take it!

[XaurDesu]

Alright! i'm taking a look into it this weekend. I'm currently a college student and i'm doing my finals, but once i'm done with those i will be making a pull request. Might read a bit of the codebase in the meantime

[XaurDesu]

Hey guys, given that there are quite a few things, do you think it would be more sensible to try and make a pull request when one is finished rather than make a big one with all of them at the same time? That way we can start merging the stuff just as i finish it, instead of waiting for the full ticket to be completed, and we can keep track of them through the checklist in this issue.

[xedin]

Either way is fine, if you want to do a PR per, go for it.

[Rajveer100]

All changes I suppose would be done in the ASTPrinter.cpp file?

[Rajveer100]

@hamishknight Could you give a brief info about this issue, although I have gone through the previous pull request and started digging about AST.

[hamishknight]

All changes I suppose would be done in the ASTPrinter.cpp file?

Yes, that's correct, specifically the ASTPrinter::visitXXXExpr methods that are currently empty.

Could you give a brief info about this issue, although I have gone through the previous pull request and started digging about AST.

@Rajveer100 This is about being able to print back out expressions from their AST node, e.g we should be able to print <expr> as <Type> given the CoerceExpr that describes it (where <expr> and <Type> are replaced with the expression and type used).

[Rajveer100]

@Rajveer100 This is about being able to print back out expressions from their AST node, e.g we should be able to print <expr> as <Type> given the CoerceExpr that describes it (where <expr> and <Type> are replaced with the expression and type used).

You mean to say, if the Abstract Syntax Tree (AST) had to evaluate an expression, like a simple math equation (3 * 7 + 13), the resulting type would be of some type (ex. <expr>) and the 'ASTPrinter' would be able to print it in a certain form (ex. <Type>)?

[Rajveer100]

Could you also give some example code snippet to 'test' any suitable cases (not necessarily among the implemented cases), for more familiarity.

[hamishknight]

@Rajveer100 You can try it out with expressions like 3 * 7 + 13 with ./swift -frontend -print-ast /path/to/file.swift. It should just print back out the original expression.

[Rajveer100]

Well actually I use Xcode WorkSpace, in the scheme, just after the -typecheck I added the -print-ast flag and it gave the following output:

/swift-project/build/CodeBase/DebugArea.swift:29:7: warning: result of operator '+' is unused
3 * 7 + 13
~~~~~ ^ ~~

3 * 7 + 13

Without the flag:

/swift-project/build/CodeBase/DebugArea.swift:29:7: warning: result of operator '+' is unused
3 * 7 + 13
~~~~~ ^ ~~

(I suppose that was the intended result?)

And I couldn't use -frontend flag as it threw 'unknown argument' error.

[hamishknight]

just after the -typecheck I added the -print-ast

You only need to specify -print-ast, but there's no harm in adding it after -typecheck, the last action will win (i.e -typecheck is ignored in this case).

(I suppose that was the intended result?)

Indeed that's the expected result

And I couldn't use -frontend flag as it threw 'unknown argument' error.

Oh, I assume the Xcode scheme is invoking swift-frontend (the frontend) instead of swift (the driver), so -frontend isn't needed. Doesn't matter, the invocations should do the same thing.