================
@@ -1029,7 +1031,9 @@ struct CompletionRecorder : public CodeCompleteConsumer {
// CodeCompletionResult doesn't seem to be const-correct. We own it,
anyway.
return const_cast<CodeCompletionResult &>(R).CreateCodeCompletionString(
*CCSema, CCContext, *CCAllocator, CCTUInfo,
- /*IncludeBriefComments=*/false);
+ /*IncludeBriefComments=*/false,
+ /*SuppressFuncParamType=*/Opts.ArgumentLists ==
----------------
HighCommander4 wrote:
> [79b945e](https://github.com/llvm/llvm-project/commit/79b945e914a02f64b2b88cdb089c6be9c944ba9d)
>
> Is something like this what you mean?
That's part of what I had in mind, but since that `SemaCCS` object is used to
create both the signature and the snippet suffix, we'd need to create and pass
around two CCS objects instead, one for each.
> FYI I'm going to be out of office until next Tuesday so I probably wont be
> able to respond until then.
No rush, I'm also traveling this week and next and will be slow to respond.
> That said, after reading more of the CCS API I am inclined to say that adding
> another union value (and updating return types) is the right move. There will
> be some churn but after looking at it closer it seems like its not a crazy
> amount of churn. Sorry for the flip-flopping!
I'm happy to leave that up to your judgment :)
https://github.com/llvm/llvm-project/pull/200103
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
