replace libparse in auto function visitor

[lucica28]

Here the problematic code would be an auto function without a return in it's body. (that should better be a void function). Important to mention that I took the liberty to get rid of part of the check, and pointless in my view: the part with mixin. I think that pretty much no one would even use return inside a mixin. Even if one might do that, they can just simply disable the check. Still, it wasn't complete before. Example:

auto f()
{
    mixin("return 0;"); // this prevents D-Scanner from throwing the warning
    mixin("retu" ~ "rn 0;"); // this doesn't
}

I think for this check the best move would be to just get rid of the mixin. If you agree @RazvanN7 , I will also add a changelog entry for that. If not, then I will try to replicate the current behavior 100%

[lucica28]

@RazvanN7 @edi33416 any idea why the tests are not running for this pr?

[RazvanN7]

Since you are now using ASTCodegen you technically have everything you need to expand the mixin and just if a return statement is present.

[lucica28]

Since you are now using ASTCodegen you technically have everything you need to expand the mixin and just if a return statement is present.

That's correct. I added an unit tests to reflect this behavior

[RazvanN7]

Suggested change

	if (auto rs = d.fbody.isReturnStatement())
	if (d.fbody.isReturnStatement())

[RazvanN7]

I don't understand the logic here. If you encounter an assert(0) you start visiting the function body again?

[lucica28]

No, I am not visiting again. The idea is that if a function has an assert(0) it should be exempt from the check.(current D-Scanner behavior) However, it's children(potentially other functions) should be checked, that's why the super.visit call. Example scenario:

auto doStuff1() // shouldn't warn
{
    auto doStuff2(){} // should warn
    assert(0);
}

[RazvanN7]

But you have already started visiting the function body by iterating through cs. It seems to me that you are doing extra work. Why not just visit each individual statement of cs?

A simpler logic would be to simply check each statement inside a function body and treat each case:

• if it's a func decl, just check it
• if it's a return statement, set foundReturnStatement
• if it's an assert set foundReturnStatement

[RazvanN7]

But you have already started visiting the function body by iterating through cs. It seems to me that you are doing extra work. Why not just visit each individual statement of cs?

A simpler logic would be to simply check each statement inside a function body and treat each case:

• if it's a func decl, just check it
• if it's a return statement, set foundReturnStatement
• if it's an assert set foundReturnStatement