[clang] [clang-format] Handle common C++ non-keyword types as such (PR #83709)
via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 6 00:09:30 PST 2024
mydeveloperday wrote:
Just thinking out loud and maybe not for this patch but for a more general solution, what we seem to never do is collect information about types local to the file as we go; For example what if a first pass identified types from declarations and function argument declarations, return types, template arguments and added them to a structure that would have some probability that a given identifier was actually a type.
Foo x;
or Bar(Foo x)
This would give "Foo" some sort of weight to it being a type, which then would give more promenance to it being a cast than a binary operation.
The problem I see and why I think I agree more with @owenca is people love to wrap logical operations in '()' so I think assuming (a) is a cast is hard especailly for the `(a) * (b)` cases, but if we had already see `a` as a type we'd at least have some more confidence that a `(a)` was a cast.
Given the example below the macro argument doesn't tell me its a type, but the `<m_type>` does as does the return type of `get()`
By the time we'd arrived at the `(m_type)*` we'd already have a good idea that this m_type was a type and not a variable and so by definition we'd say it was a cast
```
#define VARIANT_ACCESSOR_NUMBER(m_type) \
template <> \
struct VariantInternalAccessor<m_type> { \
- static _FORCE_INLINE_ m_type get(const Variant *v) { return (m_type)*VariantInternal::get_int(v); } \
+ static _FORCE_INLINE_ m_type get(const Variant *v) { return (m_type) * VariantInternal::get_int(v); } \
static _FORCE_INLINE_ void set(Variant *v, m_type p_value) { *VariantInternal::get_int(v) = p_value; } \
};
```
There is some precident for this in using the "majority" rule of something local to the file (from Jaspers original slides)
```
More important problems
int *a; or int* a;
● Clang-format has an adaptive mode:
○ Count cases in input
○ Take majority vote
```
Any thoughts?
https://github.com/llvm/llvm-project/pull/83709
More information about the cfe-commits
mailing list