capfredf marked an inline comment as not done. capfredf added inline comments.
================ Comment at: clang/lib/Interpreter/CodeCompletion.cpp:84 + std::string AllCodeText = + MainInterp.getAllInput() + "\nvoid dummy(){\n" + Buffer.str() + "}"; + auto Lines = std::count(AllCodeText.begin(), AllCodeText.end(), '\n') + 1; ---------------- capfredf wrote: > v.g.vassilev wrote: > > I am not sure why we need to wrap this code. Can we teach the > > `TopLevelStmtDecl` to work with the code completion logic? > I think the problem has less to do with the TopLevelStmtDecl. Usually, a > `TopLevelStmtDecl` instance is a successful result from `ParseXXXXX`, but > when `CodeCompletion` is triggered during parsing, nothing meaning comes out > from `ParseXXXX`. > > We need to wrap our input because we need `Sema::CodeCompleteOrdinaryName` to > work on code from the REPL in a different completion context than the same > code from a regular source file. > > In a regular C++ file, > > ``` > int foo = 42; > f_ > ``` > > Since top-level expressions are not supported, `foo` should not be an option. > > But in a REPL session, > > ``` > clang-repl> int foo = 42; > clang-repl> f_ > ``` > > we are allowed to use `foo` to make a statement like `foo + 84;`. > > Since the argument for `CompletionContext` to `CodeCompleteOrdinaryName` is > controlled by the parsing process, ie. there is no way to configure it from > outside, I think faking context is a straightforward solution. > > Alternatively, we can check if the compiler is in incremental mode and call > `CodeCompleteOrdinaryName` with the context we want in parsing. Something > like: > > ``` > if (PP.isIncrementalProcessingEnabled() { > Actions.CodeCompleteOrdinaryName(getCurScope(), Sema::PCC_Statement); > } else { > Actions.CodeCompleteOrdinaryName(getCurScope(), Sema::PCC_Namespace); > } > ``` > > I personally think both solutions are extensionally equivalent, but the > alternative is a bit intrusive. I think the combination of checking `isIncrementalProcessingEnabled` and adding a new PCC might be better since it is really a different context at the REPL Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154382/new/ https://reviews.llvm.org/D154382 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits