[clang-repl] Introduce Value to capture expression results

[junaire]

Summary

This is the first part of the RFC, which implements the initial
infrastructure used for capturing expression results.

To capture the expression, it also adds a new annotation token called
annot_input_end, which works somewhat like the annot_end_of_module token
we already have. The idea is proposed by Richard Smith, thanks!

RFC: https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493

Signed-off-by: Jun Zhang <[e-mail]>

[junaire]

Update

[junaire]

Update

[junaire]

Update

[junaire]

Update.

[junaire]

Update tests.

[junaire]

Rename the interface.

[junaire]

Support printing temporaries.

Note there's a ugly hack because I didn't find the right way to synthesize
the AST for explicit destructor call.

[junaire]

Remove extra includes

[junaire]

Add more tests

[junaire]

Update

[junaire]

Prefer one patch

[junaire]

Fix patch application failed

[junaire]

update

[junaire]

Update

[junaire]

Update.

[junaire]

Update.

[junaire]

Update comments

[junaire]

Update + Rebase

[junaire]

Update

[junaire]

Update

[v.g.vassilev]

Overall it looks like we are heading in a good direction. Here are some initial comments from my partial review.

clang/include/clang/Interpreter/Interpreter.h

107

Do we need to expose this function to the outside world?

clang/lib/Interpreter/ASTHelpers.cpp

1 ↗

(On Diff #509311)

Likewise.

clang/lib/Interpreter/ASTHelpers.h

1 ↗

(On Diff #509311)

We are missing the standard llvm header preamble. Clang seems to have slight preference to using Utils in the name. How about renaming this file to InterpreterUtils.h

clang/lib/Interpreter/IncrementalParser.cpp

22

This introduces a layering violation. Can we avoid it?

161

Why ConsumeToken is not sufficient for an annot_input_end?

clang/lib/Interpreter/IncrementalParser.h

82

Do we need to expose CodeGen in this patch?

[junaire]

Address comments.

[junaire]

clang/lib/Interpreter/IncrementalParser.cpp

161

No, we can't. ConsumeToken can't eat special tokens. See https://github.com/llvm/llvm-project/blob/fc6e91fe8184129d2395b79ce42f4495b95b0d0d/clang/include/clang/Parse/Parser.h#L494-L501

[v.g.vassilev]

clang/include/clang/Interpreter/Interpreter.h

20

We can forward declare Value.

38

We probably do not need these forward declarations.

99

This seems to be not needed as well.

104

Maybe these can go in a separate data structure called ValuePrintingInfo or similar.

117

We should not need this interface.

clang/lib/Interpreter/IncrementalParser.cpp

161

Ok, thanks!

clang/lib/Interpreter/Interpreter.cpp

37

This seems to be pointing to the old filename.

226

We should avoid cantFail here and propagate the error as we do a few lines above.

clang/lib/Interpreter/Value.cpp

2

We are missing the llvm preamble here as well.

clang/lib/Parse/ParseStmt.cpp

551

I think the cleaner solution here is to remove the global flag and pass it handleExprStmt and extend Sema::ActOnExprStmt.

[junaire]

Address more comments

[junaire]

clang/include/clang/Interpreter/Interpreter.h

117

Interpreter::CompileDecl needs it. So we don't have to do a dummy Interp.Parse("") to get a llvm::Module.

clang/lib/Parse/ParseStmt.cpp

551

I dont understand, can you elaborate a bit?

[junaire]

Update

[junaire]

Update.

[junaire]

I dont know why the premerge tests are failling, let me try to do a update...