Provide definitions for std::size_t and std::ptrdiff_t through type deduction

[YexuanXiao]

I previously added a feature to Clang that allows expressions producing size_t and ptrdiff_t through built-in language mechanisms (eg. sizeof) to have the sugared types __size_t and __ptrdiff_t, instead of unsigned int/long/long long and int/long/long long (llvm/llvm-project#143653). This helps generate more portable diagnostic messages. However, the definitions of size_t and ptrdiff_t in the STL and vcruntime.h are hardcoded to fixed built-in types, causing this benefit to be lost when arithmetic operations are performed, as Clang does not treat std::size_t and std::ptrdiff_t differ from other typedefs when evaluates common sugared types.

By using deduction to define std::size_t and std::ptrdiff_t, this advantage can be preserved.

[frederick-vs-ja]

As MSVC has supported typeof/__typeof__, perhaps we should also consider changing vcruntime.h and treat the changes in MSVC STL transitional. CC @StephanTLavavej.

E.g.

#ifdef __cplusplus
using size_t    = decltype(sizeof(0));
using ptrdiff_t = decltype(static_cast<int*>(nullptr) - static_cast<int*>(nullptr));
#else // ^^^ defined(__cplusplus) / !defined(__cplusplus) vvv
typedef __typeof__(sizeof(0)) size_t;
typedef __typeof__((int*)0 - (int*)0) ptrdiff_t;
#endif // ^^^ !defined(__cplusplus) ^^^

[YexuanXiao]

As MSVC has supported typeof/__typeof__, perhaps we should also consider changing vcruntime.h and treat the changes in MSVC STL transitional. CC @StephanTLavavej.

DevCom-10957789

[StephanTLavavej]

Thanks for filing DevCom-10957789. I strongly believe that if we make a change here, it should be in VCRuntime - the STL shouldn't define these typedefs differently (even if compilers accept them being the same fundamental type). The risk of bizarre fallout is simply too great to be worth the incremental benefit.

It would help to note in that suggestion what version of Clang this will appear in. (Clang 22?)

I'm going to close this PR without merging, but thanks for looking into this and improving Clang.

[YexuanXiao]

It would help to note in that suggestion what version of Clang this will appear in. (Clang 22?)

Yes, it's expected in the Clang 22 release.