hahnjo wrote:
> > As far as I can tell, -fincremental-extensions should set the language
> > option IncrementalExtensions which in turn is the default for
> > Preprocessor::IncrementalProcessing.
>
> It is true that it is the default, but it's possible for clients to have one
> without the ot
bnbarham wrote:
> As far as I can tell, -fincremental-extensions should set the language option
> IncrementalExtensions which in turn is the default for
> Preprocessor::IncrementalProcessing.
It is true that it is the default, but it's possible for clients to have one
without the other. This
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
