<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="">Tim,</div><div class=""><br class=""></div>FWIW, I think that one got incorrectly marked as a starter bug. I don’t think the bug is fixable as written. You are right about the immediate cause, and I think that the only thing we _can_ do is mark it conservatively, because that part of the code isn’t type-checked at all, and probably can’t be, if it is #if’d out due to it being for some other version of Swift. That variable could be passed to mutable functions or operators which don’t actually exist in this version of Swift, so there’s no knowing for certain whether it’s actually read or written.<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Greg<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 18, 2016, at 2:18 PM, Timothy Wood via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Looking through the ‘StarterBug’ tag, I started looking into <<a href="https://bugs.swift.org/browse/SR-580" class="">https://bugs.swift.org/browse/SR-580</a>>, in which:<br class=""><br class="">func foo(x: Int) -> Int {<br class=""> var result = x + 1<br class="">#if NOT_ENABLED<br class=""> _ = result<br class="">#endif<br class=""> return result<br class="">}<br class=""><br class="">does not warn that “result" was never written to.<br class=""><br class="">The immediate cause seems to be in lib/Sema/MiscDiagnostics.cpp, in VarDeclUsageChecker::handleIfConfig(). This code walks the inactive #if blocks and does:<br class=""><br class=""> // If we see a bound reference to a decl in an inactive #if block, then<br class=""> // conservatively mark it read and written. This will silence "variable<br class=""> // unused" and "could be marked let" warnings for it.<br class=""> if (auto *DRE = dyn_cast<DeclRefExpr>(E)) {<br class=""> VDUC.addMark(DRE->getDecl(), RK_Read|RK_Written);<br class=""> }<br class=""><br class="">In trying to replace that with something that really walks the Expr (by calling VDUC.walkToExprPre() instead or something of the like), I run into a bunch of checks like this:<br class=""><br class=""> // Sema leaves some subexpressions null, which seems really unfortunate. It<br class=""> // should replace them with ErrorExpr.<br class=""> if (E == nullptr || !E->getType() || E->getType()->is<ErrorType>()) {<br class=""> sawError = true;<br class=""> return;<br class=""> }<br class=""><br class="">And, if I dump the AST for the test case, it has this section with all sorts of nulls:<br class=""><br class=""> (#if_stmt<br class=""> (#if:<br class=""> (unresolved_decl_ref_expr type='<null>' name=NOT_ENABLED specialized=no)<br class=""> (elements<br class=""> (sequence_expr type='<null>'<br class=""> (discard_assignment_expr type='<null>')<br class=""> (assign_expr<br class=""> (**NULL EXPRESSION**)<br class=""> (**NULL EXPRESSION**))<br class=""> (declref_expr type='<null>' decl=main.(file).func decl.qqq@/Users/bungi/Desktop/SR-580.swift:2:7 specialized=yes))))<br class=""><br class="">Presumably VarDeclUsageChecker::handleIfConfig() could pass the right subset of RK_Read|RK_Written if the declref_expr had its accessType set, or maybe a more complete AST that could be walked.<br class=""><br class="">So, then I started looking into places that look for IfConfig{Stmt,Decl} and bail, and found ASTWalker.cpp’s Traversal::visitIfConfigStmt(), and TypeCheckStmt.cpp’s visitIfConfigStmt(). I hacked in a walk() call in the Traversal case and broke all sorts of stuff (maybe since I didn’t do something similar in TypeCheckStmt.cpp). That was about the point that I thought I’d ask if I’m digging in the wrong spot =)<br class=""><br class="">Presumably making more work get done for inactive #if branches will slow down the compiler some (hopefully the percentage of existing code inside a #if block at all is pretty low). But, worse, I can imaging there is a ton of other stuff in them that will cause errors if more of the compiler runs on them (whole missing types, selectors, …).<br class=""><br class="">Is this direction even worth pursuing? Maybe I should look into whether there is a quicker way to get the access type of the declref_expr set when it is being created during the inactive #if parsing?<br class=""><br class="">Thanks!<br class=""><br class="">-tim<div class=""><br class=""></div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>