[REG2.031] Issue 14965 - Forward reference to inferred return type of function call when using auto return type

[9rnsr]

https://issues.dlang.org/show_bug.cgi?id=14965

If a function symbol is used, its overload resolution should be deferred until:

func(...)           // CallExp.semantic
func.mangleof       // DotIdExp.semanticY
typeof(func)        // TypeTypeof.resolve
typeof(&func)       // TypeTypeof.resolve
auto v = &func;     // ExpInitializer.inferType
&func;              // ExpStatement.semantic
return &func;       // ReturnStatement

When the semantic analysis reaches to them, the function forward reference can beome actual error.

Other use of 'func' should be treated as a property-like function call (done in resolveProperties) and finally handled in CallExp.

---

Each preparation cleanup/refactoring changes are separated into following pull requests.

• Cleanup dcast.d #5197 Cleanup dcast.d
• Cleanup hasOverloads #5198 Cleanup hasOverloads
• Refactor: TypeTypeof.resolve #5199 Refactor: TypeTypeof.resolve

[dlang-bot]

Fix	Bugzilla	Description
✓	14965	[REG2.031] Forward reference to inferred return type of function call when using auto return type

[9rnsr]

Now this PR contains only one bugfix commit. Ready to go.

[MartinNowak]

It's very maintenance intensive to do something by dealing with all occurrences of it in the language.
While your work is an improvement, can we boil it further down to something more fundamental like requiring the type of an expression.

[9rnsr]

I'm continuously boiling down things. It's easy to add one new thing quickly, but it's dangerous because we should handle all interactions at once between the new thing and other all existing AST entities. So, we usually should be conservative not to add new things.

(OT: I'm proposing to add a new AST entity "ambiguous function type and its derived types" in #2130, but the PR didn't get enough response during 3 years.)

[MartinNowak]

It's easy to add one new thing quickly, but it's dangerous because we should handle all interactions at once between the new thing and other all existing AST entities. So, we usually should be conservative not to add new things.

I think we should try to refactor our code, so it's less hard to add all those interactions. It's also a big maintenance overhead to deal w/ behavior that's scattered throughout the codebase.
But we should still be conservative to add new features, simply b/c we want the language to stabilize.

[MartinNowak]

So to rephrase my question, can we combine this check w/ something else we already do?
Or at least put it into a more abstract needsExactType/needsResolvedSymbol function or so?
What's the common denominator of all the above mentioned expressions. Why is AddrExpr in ReturnStatement different from AddrExp in initializer?
We already have inferType for when the result of an expression depends on the LHS.

[9rnsr]

I think we should try to refactor our code

I agree with you at all, but refactoring is less priority than regression fixes. So I usually don't do unuseful refactoring for bugfixes near the future.

can we combine this check w/ something else we already do?

No we cant yet, because function overload handling is yet incomplete (See issue 1983 and others). In other words, we are in progress to find it.

Or at least put it into a more abstract

It was impossible. In this PR, I added two abstracts isFuncAddress and checkForwardRef. In early stage I tried to merge them into one, but couldn't because of subtle existing behavior differences in TypeTypeof, AddrExp, etc.
Now, the differences stand out by the two abstracts. Of course later we can decide how to handle them, but we should not touch them now, because this is for 14965 bugfix.

[MartinNowak]

Auto-merge toggled on

[9rnsr]

@MartinNowak Thanks!