================
@@ -364,15 +366,34 @@ int main(int argc, const char **argv) {
}
Input += L;
+ // If we add more % commands, there should be better architecture than
+ // this.
if (Input == R"(%quit)") {
break;
}
if (Input == R"(%undo)") {
if (auto Err = Interp->Undo())
llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
+ } else if (Input == R"(%help)") {
+ OS << "%help\t\tlist clang-repl %commands\n"
----------------
DavidSpickett wrote:
I didn't think of that. That's a good question to be asking. I checked it:
```
/// This returns a reference to a raw_fd_ostream for standard output. Use it
/// like: outs() << "foo" << "bar";
LLVM_ABI raw_fd_ostream &outs();
```
And 1: the example uses outs() directly, so that's a big hint that it's fine.
2: It does create a raw_fd_ostream each time, but it always points to stdout.
So it's not going to be doing much work constructing the wrapper.
There is one instance of someone doing `= llvm::outs();` outside a loop and
reusing it, but there are plenty more where they don't.
But like you say, it's only going to be used for `%help` so if you're doing
that, you're at an interactive prompt, and the performance there is not a
problem or if it is, there are bigger issues than a few wrapper objects.
Again though, good thing to be thinking about. C++ especially can be very
sneaky.
https://github.com/llvm/llvm-project/pull/150348
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
