ArcsinX 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`
```cpp
#pragma once
struct Something { int I = 0; };
```
`test.cpp`
```cpp
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?
https://github.com/llvm/llvm-project/pull/212134
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
