[PATCH] D140828: [C++] Implement "Deducing this" (P0847R7)

Thu Aug 10 08:08:14 PDT 2023

cor3ntin marked 9 inline comments as done.
cor3ntin added inline comments.

================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7280
+  "a %select{function|lambda}0 with an explicit object parameter cannot "
+  "%select{be const|be mutable|have reference qualifiers|be volatile}1">;
+def err_invalid_explicit_object_type_in_lambda: Error<
----------------
aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > cor3ntin wrote:
> > > > aaron.ballman wrote:
> > > > > I think you're missing `restrict` here as well. Perhaps this is a case where it's better to diagnose the qualifiers generically and rely on the diagnostic's source range? e.g., `cannot have qualifiers` instead of the current %1 selection. This also works around weird with things like `void func() const &;` where it has multiple qualifiers.
> > > > Forming a source range to the qualifiers may be challenging though.
> > > > 
> > > > In what case would `restrict` come into play?
> > > > 
> > > > ```
> > > > struct test {
> > > >     void f() restrict;
> > > > };
> > > > ```
> > > > does not seem valid, I'm assuming  it is in some language mode?
> > > Ah, it's spelled `__restrict` in C++ mode, but we also support other qualifiers like `_Nonnull` as well. I left some examples in other comments that should demonstrate this.
> > Maybe we need a way to compute the range of all qualifiers. I'll look into that - I'm not sure the information exists atm.
> > SourceLocation objects are ordered, right?
> Correct, source locations are ordered; you can use `SourceManager::isBeforeInTranslationUnit()` to compare orderings within the same TU.
Thanks! I ended up using a different approach though

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140828/new/

https://reviews.llvm.org/D140828