<div dir="ltr">Oops... I updated clang to 3.3 trunk, and found another bug...<div><br></div><div>In Sema::checkPseudoObjectIncDec(), op may be type-dependent, but this fact can only be discovered if you do a buildGet().</div>
<div>So the first op->isTypeDependent() check will still fail to detect this fact.</div><div style>Sema::checkPseudoObjectAssignment() doesn't have this problem.</div><div style><br></div><div style>Override ExprResult Sema::checkPseudoObjectIncDec() to handle this situation.</div>
<div style><br></div><div style>Patch & test attached.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 3:59 PM, <a href="mailto:endlessroad1991@gmail.com">endlessroad1991@gmail.com</a> <span dir="ltr"><<a href="mailto:endlessroad1991@gmail.com" target="_blank">endlessroad1991@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Well, thank you :-)<div><br></div><div>I'm not planning to work on subscriptable properties, because our project doesn't involve that, and I still think subscriptable property is full of undocumented behavior and is rarely used.</div>
<div><br></div><div>However, I have another patch to provide support for "for each", also well-tested by our codebase. However, I think this feature is not useful, but if someone needs it I can post it here.</div>
<div><br></div><div>I want to continue work on clang C++ support on WIndows. I understand that the main problem is MSVC ABI. Do you have someone to refer to?</div><div><br></div><div>Thanks.</div></div>
<div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 3:48 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div><div>On Apr 15, 2013, at 8:53 PM, <a href="mailto:endlessroad1991@gmail.com" target="_blank">endlessroad1991@gmail.com</a> wrote:</div><blockquote type="cite"><div dir="ltr">
Last problem:<div><div style="font-family:arial,sans-serif;font-size:13px"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">2. In Sema/SemaExpr.cpp, ActOnCallExpr():</div><div>I admit that I'm not very thorough about this one...</div>
<div>But here the CheckPlaceholderExpr() call does solve the follwing problem.</div><div>=== Code Start ===</div><div><div>// If compiled with -ggdb, clang will crash and saying something about</div><div>// "unexpected builtin-type" in some CG code.</div>
<div><br></div><div>struct S2 {</div><div><span style="white-space:pre-wrap"> </span>template <class T></div><div><span style="white-space:pre-wrap"> </span>void f(T t) {}</div><div>};</div><div><br></div><div>template <class T></div>
<div>struct S</div><div>{</div><div><span style="white-space:pre-wrap"> </span>__declspec(property(get=GetV)) int V;</div><div><span style="white-space:pre-wrap"> </span>int GetV() { return 123; }</div><div><span style="white-space:pre-wrap"> </span>void f() { S2 s2; s2.f(V); }</div>
<div>};</div><div><br></div><div>int main() {</div><div><span style="white-space:pre-wrap"> </span>S<int> s;</div><div><span style="white-space:pre-wrap"> </span>s.f();</div><div>}</div></div><div>=== Code End ===</div>
</div></div></blockquote><div><br></div></div>Ah, I think the problem here is that overload resolution and especially</div><div>template argument deduction aren't lowering out placeholder types. Please</div><div>hoist this loop out of the C++ block (for obscure reasons; just trust me)</div>
<div>and check:</div><div> hasPlaceholderType(BuiltinType::PseudoObject)</div><div>instead of checking for a particular expression kind.</div><div><br></div><div>And please add this as a test case. :)</div></div></blockquote>
</div></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div>This change leads to a test failure:</div><div>test/SemaObjc/property-user-setter.m, Line 88:</div><div>void g(int); // expected-note {{passing argument to parameter here}}<br>
</div><div>this note is no longer printed.</div><div>If it's fine, wen can just remove the expected-note comment, but I don't know if it's appropriate.</div></div></div></blockquote><br></div></div></div><div>
The note's not particularly important, no. The context of initializing a parameter doesn't really have much to do with the failure to load the property.</div><div><br></div><div>This looked really good, so I spent a little time tweaking it and then committed it as r179585, thanks!</div>
<div><br></div><div>The main changes I made were:</div><div> - I tweaked a lot of the diagnostic text to just talk about properties instead of saying __declspec(property).</div><div> - I also changed the diagnostic names to make it clear that they were specific to MS properties.</div>
<div> - I reworked the parsing code to avoid some redundant diagnostics and recover nicely in some ways. For example, if you try to say set=setX, it'll tell you to write put=setX.</div><div> - Properties have to be bare identifiers, so there is no point in storing a full DeclarationNameInfo; it's always just a SourceLocation.</div>
<div><br></div><div>Please don't let the number of changes dishearten you; it was all just small tweaks, and this was really great work!</div><div><br></div><div>Are you planning to work on subscriptable properties, or was this enough to get your project ported?</div>
<span><font color="#888888"><div><br></div><div>John.</div></font></span></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="im">-- <br>Best Regards, Tong Shen (ÉòÍ®)
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Best Regards, Tong Shen (ÉòÍ®)
</div>