This patch should close Bug 35951.
|652 ↗||(On Diff #131422)|
Is there a reason why the places that compute the type of these l-value expressions don't propagate qualiifers? This hardly seems restricted to 'const'.
That's still just const-propagation. The const qualifier on the pointee type of this should propagate to the l-value resulting from the member access, and the vector-specific projection logic should continue to propagate const to the type of the element l-value.
I'm afraid it's wrong because from my point of view Clang generates wrong message for test OhNo3 (see err_typecheck_assign_const.cpp). It should not be "read-only variable is not assignable" because v is not read-only variable. Any other non-const method is able to change this variable w/o any problems. The the same is for OhNo and OhNo2.
BTW, gcc generates
error: assignment of read-only location ‘*(const float*)(&((const OhNo2*)this)->OhNo2::v)’
and that's OK because we try to change the value through const-pointer-to-const. Am I right?
If you just want a better diagnostic, there's quite a bit of machinery already set up to give more specific errors about why such-and-such l-value isn't modifiable. There may even be vector-specific diagnostics for that already, just triggered from the wrong place in the code.
No, really, in CreateBuiltinArraySubscriptExpr and LookupMemberExpr, in the clauses where they handle vector types, you just need to propagate qualifiers from the base type like is done in BuildFieldReferenceExpr. There's even a FIXME about it in the former.