https://github.com/hahnjo closed
https://github.com/llvm/llvm-project/pull/102450
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vgvassilev approved this pull request.
Lgtm!
https://github.com/llvm/llvm-project/pull/102450
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> Your reasoning sounds right to me. Can we make sure we are not breaking
> `clang -fincremental-extensions`, too?
As far as I can tell, `-fincremental-extensions` should set the language option
`IncrementalExtensions` which in turn is the default for
`Preprocessor::IncrementalP
vgvassilev wrote:
Your reasoning sounds right to me. Can we make sure we are not breaking `clang
-fincremental-extensions`, too?
https://github.com/llvm/llvm-project/pull/102450
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Jonas Hahnfeld (hahnjo)
Changes
When incremental processing is enabled, the Parser will never report `tok::eof`
but `tok::annot_repl_input_end`. However, that case is already taken care of in
`IncrementalParser::ParseOrWrapTopLevelDecl()`
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/102450
When incremental processing is enabled, the Parser will never report `tok::eof`
but `tok::annot_repl_input_end`. However, that case is already taken care of in
`IncrementalParser::ParseOrWrapTopLevelDecl()` so t
