hongtaihu wrote:
> > Investigated this further. `DeclarationNameInfo` is correct here: parser
> > recognizes `operator ::align_val_t` as a conversion-function-id, and Sema
> > constructs a `CXXConversionFunctionName` with a target type.
> > The incorrect step was in `UnresolvedNameRecorder`: it unconditionally
> > called `Typo.getAsString()` and treated the diagnostic presentation string
> > as `UnresolvedName::Name`. For this kind, that string contains the target
> > type and can contain `std::`, which is not an outer lookup scope that
> > IncludeFixer can split into `Name + Scopes`.
> > I updated the patch to reject only `CXXConversionFunctionName` before this
> > lossy conversion. This removes the string-based `contains("::")` check. I
> > intentionally do not reject all non-identifier names: e.g. overloaded
> > operators may still be valid unqualified index names.
>
> I’m not sure it’s right to always reject `CXXConversionFunctionName`.
>
> E.g. `test.h`
>
> ```c++
> #pragma once
> struct Something { int I = 0; };
> ```
>
> `test.cpp`
>
> ```c++
> struct Wrapper {
> template <typename T>
> operator T() const { return T(); }
> };
>
> void f() {
> Wrapper W;
> auto V = W.operator::Something();
> }
> ```
>
> test.cpp will have compilation error, which can be fixed with test.h include.
> So, the question is, will we reject such a case with this patch or not?
I have changed the condition.
Now it only rejects `CXXConversionFunctionName`.
https://github.com/llvm/llvm-project/pull/212134
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
