<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 31, 2016, at 2:47 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">CS.getType(FVE) already gets rid of the optionality, so the lookThrough/getAnyOptionalObjectType isn't necessary at all.</div></div></blockquote><div><br class=""></div><div>Ah, sorry, quite right.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I'm still not sure whether this is the right solution. Are there no other expression types that need similar treatment? Is ASTWalker really the right tool for this job? These are questions for someone who knows CSGen better than I…</div></div></div></blockquote><div><br class=""></div><div>At the moment that would be Joe Pamer, but there’s some... conflicts that occur going down that path. As for why this works with non-chained binops no simplification occurs in that case because, well, there’s no chain here. The solver walks each part in turn instead. </div><div><br class=""></div><div>The walker is, I think, appropriate. It is a very domain-specific optimization that doesn’t quite know about its entire domain yet. However, I don’t think anyone would be opposed to a little meta-programming with an ASTVisitor to refactor it into a more manageable form.</div><div><br class=""></div><div>~Robert Widmann</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Sat, Dec 31, 2016 at 1:31 PM, Robert Widmann <span dir="ltr" class=""><<a href="mailto:devteam.codafi@gmail.com" target="_blank" class="">devteam.codafi@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Whoops, should only look through one level of optionality. You get the gist.</div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">~Robert Widmann</div></font></span><div class=""><div class="gmail-h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2016, at 2:31 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" target="_blank" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="gmail-m_-436856257548543851Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">I taught <span style="font-family:menlo;font-size:11px" class="">LinkedExprAnalyzer </span>abou<wbr class="">t <span style="color:rgb(79,129,135);font-family:menlo;font-size:11px" class="">ForceValueExpr</span></div><div class=""><br class=""></div><div class=""><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""> </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="">if</span><span style="font-variant-ligatures:no-common-ligatures" class=""> (</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="">auto</span><span style="font-variant-ligatures:no-common-ligatures" class=""> FVE = </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(62,30,129)" class="">dyn_cast</span><span style="font-variant-ligatures:no-common-ligatures" class=""><</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)" class="">ForceValueExpr</span><span style="font-variant-ligatures:no-common-ligatures" class="">>(expr)<wbr class="">) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(49,89,93)" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""> </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)" class="">LTI</span><span style="font-variant-ligatures:no-common-ligatures" class="">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)" class="">collectedTypes</span><span style="font-variant-ligatures:no-common-ligatures" class="">.</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(62,30,129)" class="">insert</span><span style="font-variant-ligatures:no-common-ligatures" class="">(</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)" class="">CS</span><span style="font-variant-ligatures:no-common-ligatures" class="">.</span><span style="font-variant-ligatures:no-common-ligatures" class="">g<wbr class="">etType</span><span style="font-variant-ligatures:no-common-ligatures" class="">(FVE)-></span><span style="font-variant-ligatures:no-common-ligatures" class="">lookThroughAllAny<wbr class="">OptionalTypes</span><span style="font-variant-ligatures:no-common-ligatures" class="">().</span><span style="font-variant-ligatures:no-common-ligatures" class="">getPointer</span><span style="font-variant-ligatures:no-common-ligatures" class="">());</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""> </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="">return</span><span style="font-variant-ligatures:no-common-ligatures" class=""> { </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="">false</span><span style="font-variant-ligatures:no-common-ligatures" class="">, expr };</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""> }</span></div></div><div class=""><br class=""></div><div class="">This seems to get it - didn’t check whether this regresses things, but this seems to be the right fix at a high level.</div><div class=""><br class=""></div><div class="">~Robert Widmann</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2016, at 11:22 AM, Mark Lacey via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class="gmail-m_-436856257548543851Apple-interchange-newline"><div class=""><div dir="auto" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="gmail-m_-436856257548543851Apple-interchange-newline">On Dec 30, 2016, at 2:07 PM, Jacob Bandes-Storch via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class="gmail-m_-436856257548543851Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is a pretty great bug:<span class="gmail-m_-436856257548543851Apple-converted-space"> </span><a href="https://bugs.swift.org/browse/SR-3483" target="_blank" class="">https://bugs.swift.org/<wbr class="">browse/SR-3483</a><div class=""><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class=""> let x: Double? = 1</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> </font><span style="font-family:monospace,monospace" class="">// error: ambiguous reference to member '+'</span></div><div class=""><font face="monospace, monospace" class=""> let sum = x! + x! + x!</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> </font><span style="font-family:monospace,monospace" class="">// error: value of optional type 'Double?' not unwrapped; did you mean to use '!' or '?'?</span></div><div class=""><font face="monospace, monospace" class=""> let sum: Double = x! + x! + x!</font></div></div><div class=""><br class=""></div><div class="">I've been poking around and I think the problem might be in LinkedExprAnalyzer.<span class="gmail-m_-436856257548543851Apple-converted-space"> </span></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah I think you’re onto something there. Just looking at the output of the constraint solver and where bindings are happening in matchTypes(), it looks like the constraint optimizer is trying to force the result type of both adds to ‘Double?’ rather than ‘Double’, so we only ever try to solve for that type.</div><div class=""><br class=""></div><div class="">I haven’t looked at the constraint optimizer code in a while, so I don’t have a lot of insight into the best fix, but it’s clearly the problematic piece here.</div><div class=""><br class=""></div><div class="">Mark</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">This class collects type info about elements in a chain of binary operators to speed up constraint solving. It does so in this case by grabbing the DeclRefExpr's type:<span class="gmail-m_-436856257548543851Apple-converted-space"> </span><a href="https://github.com/apple/swift/tree/474096b9cbd6ff7ac998d7cea41d629512e25570#L230-L239" target="_blank" class="">https://github.com/<wbr class="">apple/swift/tree/<wbr class="">474096b9cbd6ff7ac998d7cea41d62<wbr class="">9512e25570#L230-L239</a></div><div class=""><br class=""></div><div class="">However, since this is an ASTWalker, (I think) it automatically traverses into the ForceValueExpr without remembering that the type it finds inside (from the DeclRefExpr) should have one level of optionality removed when added to the constraint system.</div><div class=""><br class=""></div><div class="">This theory sort of makes sense to me, but it doesn't explain why the simpler "<font face="monospace, monospace" class="">let sum = x! + x!</font>" typechecks correctly, because that goes through the same code path.</div><div class=""><br class=""></div><div class="">Am I correct that the LinkedExprAnalyzer probably needs to make sure it doesn't keep the Optional when adding the type of a ForceValueExpr? Why wouldn't this also cause problems for a single binop application?</div><div class=""><br class=""></div><div class="">Would it be more appropriate for LinkedExprAnalyzer to be an ASTVisitor (ExprVisitor) so that instead of just saying "yes, continue traversing downwards" (by returning {true, expr}), its ForceValueExpr case could recursively call visit() and then getAnyOptionalObjectType on the result?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Semi-eptly,</div><div class=""><div class=""><div class="gmail-m_-436856257548543851gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div></div></div></div>______________________________<wbr class="">_________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></div><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">______________________________<wbr class="">_________________</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">swift-dev mailing list</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="mailto:swift-dev@swift.org" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-dev@swift.org</a><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>