avt77 closed this revision.
avt77 added a comment.
Fixed by 324721.
https://reviews.llvm.org/D42530
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RKSimon added a comment.
@avt77 Close this now that https://reviews.llvm.org/rL324721 has landed?
https://reviews.llvm.org/D42530
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
avt77 added a comment.
Committed revision 324721.
BTW, could you review https://reviews.llvm.org/D42728: it's rather similar to
this one and rather small as well.
https://reviews.llvm.org/D42530
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
rjmccall added a comment.
Thanks, that looks a lot better. One minor piece of feedback, but otherwise
LGTM.
Comment at: lib/Sema/SemaExpr.cpp:4402
+Qualifiers MemberQuals =
+Context.getCanonicalType(ResultType).getQualifiers();
+Qualifiers Combined = BaseQuals
avt77 updated this revision to Diff 133404.
avt77 added a comment.
I propagated qualifiers accordingly to rjmccall's suggestion. But I changed the
diagnostic: now it's more realistic from my point of view.
https://reviews.llvm.org/D42530
Files:
lib/Sema/SemaExpr.cpp
lib/Sema/SemaExprMember
rjmccall added a comment.
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.
https:/
avt77 updated this revision to Diff 132607.
avt77 added a comment.
I re-implemented the patch. Now it works properly with const methods in CXX
classes.
https://reviews.llvm.org/D42530
Files:
lib/AST/ExprClassification.cpp
lib/Sema/SemaExpr.cpp
test/Sema/assign.c
test/Sema/typedef-retai
rjmccall added a comment.
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
avt77 added a comment.
In https://reviews.llvm.org/D42530#995227, @rjmccall wrote:
> 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 contin
rjmccall added a comment.
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.
htt
avt77 added a comment.
In fact we have here another problem: it is not an attempt to assign to const
variable but it is an attempt to use the field assingment inside const method:
I'm working on it.
https://reviews.llvm.org/D42530
___
cfe-commits
rjmccall added inline comments.
Comment at: lib/AST/ExprClassification.cpp:652
+if (Ctx.getCanonicalType(ASE->getBase()->getType()).isConstQualified())
+ return Cl::CM_ConstQualified;
+
avt77 wrote:
> rjmccall wrote:
> > Is there a reason why the places
avt77 added inline comments.
Comment at: lib/AST/ExprClassification.cpp:652
+if (Ctx.getCanonicalType(ASE->getBase()->getType()).isConstQualified())
+ return Cl::CM_ConstQualified;
+
rjmccall wrote:
> Is there a reason why the places that compute the typ
rjmccall added inline comments.
Comment at: lib/AST/ExprClassification.cpp:652
+if (Ctx.getCanonicalType(ASE->getBase()->getType()).isConstQualified())
+ return Cl::CM_ConstQualified;
+
Is there a reason why the places that compute the type of these l-va
14 matches
Mail list logo
