<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 8, 2014 at 7:23 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right now we only emit the "function/variable has internal linkage but is not defined" warning at end of TU if no errors were encountered.<br>
<br>
However we probably shouldn't skip checkUndefinedButUsed() so liberally. It causes lack of test coverage (doesn't appear in any -verify + expected-error test) and loss of useful information for users.<br>
<br>
Best guess is that it came to be this way back when bodies used to get skipped liberally in error recovery. Nowadays we're tracking definitions effectively and should be able to enable the checks unconditionally.<br>
<br>
Simple enough?</blockquote><div><br></div><div>I think there are other reasons for this. For instance:</div><div><br></div><div>inline void foo();</div><div>void bar() { foo(); }</div><div>int foo() {}</div><div><br></div>
<div>... doesn't get an 'internal linkage but is not defined' error currently; I think it would with the change you're proposing.</div><div><br></div><div>It seems like the justification for this change is that users lose information (the test coverage problem can be solved in ways that aren't visible to users). I think that's fair, but it's very hard to distinguish real problems from false ones here.</div>
<div><br></div><div>Perhaps we could try to distinguish between "top-level" errors (which might affect the set of definitions available) and errors within function definitions and the like. Thoughts?</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now for the bad news..<br>
<br>
There are 26 tests relying on not using undefined inline functions:<br>
<br>
Failing Tests (26):<br>
Clang :: CXX/dcl.dcl/dcl.spec/dcl.<u></u>constexpr/p3.cpp<br>
Clang :: CXX/dcl.dcl/dcl.spec/dcl.<u></u>constexpr/p8.cpp<br>
Clang :: CXX/drs/dr2xx.cpp<br>
Clang :: CXX/drs/dr3xx.cpp<br>
Clang :: CXX/drs/dr4xx.cpp<br>
Clang :: CXX/expr/expr.const/p2-0x.cpp<br>
Clang :: CXX/expr/expr.prim/expr.prim.<u></u>lambda/p19.cpp<br>
Clang :: CXX/stmt.stmt/stmt.iter/stmt.<u></u>ranged/p1.cpp<br>
Clang :: CXX/temp/temp.arg/temp.arg.<u></u>nontype/p1.cpp<br>
Clang :: CXX/temp/temp.arg/temp.arg.<u></u>type/p2.cpp<br>
Clang :: CXX/temp/temp.fct.spec/temp.<u></u>deduct/temp.deduct.partial/<u></u>p11.cpp<br>
Clang :: Modules/namespaces.cpp<br>
Clang :: Modules/redecl-add-after-load.<u></u>cpp<br>
Clang :: Parser/cxx-ambig-paren-expr.<u></u>cpp<br>
Clang :: Parser/recovery.cpp<br>
Clang :: Sema/array-init.c<br>
Clang :: Sema/inline.c<br>
Clang :: Sema/invalid-decl.c<br>
Clang :: SemaCXX/anonymous-struct.cpp<br>
Clang :: SemaCXX/explicit.cpp<br>
Clang :: SemaCXX/expression-traits.cpp<br>
Clang :: SemaCXX/lambda-expressions.cpp<br>
Clang :: SemaCXX/new-delete.cpp<br>
Clang :: SemaCXX/overload-call.cpp<br>
Clang :: SemaCXX/typo-correction.cpp<br>
Clang :: SemaTemplate/deduction.cpp<br>
<br>
For each we need to figure out the right fix, which varies case by case:<br>
<br>
a) add a definition body {}<br>
b) de-inline the declaration<br>
c) add expected-warning {{}}<br>
d) or just run -Wno-undefined-internal in tests where it doesn't matter<br>
<br>
* (c) and (d) will be problematic when the warning becomes a hard error as planned in Sema FIXMEs.<br>
<br>
So, if we want to apply the patch fixing the issue we'll need to update all those tests to valid syntax.<br></blockquote><div><br></div><div>=( The size of this cleanup for me swings the cost/benefit tradeoff somewhat towards "do nothing". The diagnostic will still get produced once the other errors have been fixed. But if someone wants to run with this, sure...<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The attached patch implements the fix and demonstrates each one of the strategies to get started. Thoughts/volunteers? :-)<br>
<br>
Related to:<br>
PR19910 - Don't suppress unused/undefined warnings when there are errors<br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=19910" target="_blank">http://llvm.org/bugs/show_bug.<u></u>cgi?id=19910</a><br>
<br>
Historical context:<br>
PR5933 - bogus unused variable warning after error<br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=5933" target="_blank">http://llvm.org/bugs/show_bug.<u></u>cgi?id=5933</a><span class="HOEnZb"><font color="#888888"><br>
<br>
Alp.<br>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</font></span></blockquote></div><br></div></div>