auto a() { b(); }
auto b() { a(); }
---
main.d(2): Error: forward reference to a
---
Comment #1 by timon.gehr — 2013-08-12T13:07:40Z
I think this is expected behaviour and this issue is an enhancement.
Exactly which additional cases do you want to make work?
Comment #2 by henning — 2013-08-12T16:44:06Z
What do you mean with "additional cases"? The return types of these functions don't depend on each other. The code should compile just like this does:
void a() { b(); }
void b() { a(); }
Comment #3 by timon.gehr — 2013-08-12T19:01:18Z
(In reply to comment #2)
> What do you mean with "additional cases"?
The D programs that compile after the fix that wouldn't have compiled before.
> The return types of these functions don't depend on each other.
Indeed, but in order to fix this issue, we need a computationally decidable notion of dependence of function return types.
Currently, this is quite conservative. Analysis of any function is suspended if a function call with unresolved return type is encountered, until this return type has been resolved.
Comment #4 by henning — 2013-08-12T19:20:42Z
> The D programs that compile after the fix that wouldn't have compiled
> before.
I just wondered what DMD would do when I throw this at it. Of course those return type depencies can get awfully complex and can involve tons of functions.
> Indeed, but in order to fix this issue, we need a computationally decidable
> notion of dependence of function return types.
And it will be hard to get this implemented. The current behavior is neither surprising nor dangerous. De facto no one will encounter this bug so I will lower the importance to minor.
Comment #5 by dlang-bugzilla — 2017-07-02T13:08:31Z
(In reply to timon.gehr from comment #3)
> Currently, this is quite conservative. Analysis of any function is suspended
> if a function call with unresolved return type is encountered, until this
> return type has been resolved.
Short-circuiting return type analysis to "void" if there are no return statements in the body seems like a reasonable way to solve this particular case to me.
Comment #6 by timon.gehr — 2017-07-02T13:36:08Z
(In reply to Vladimir Panteleev from comment #5)
> (In reply to timon.gehr from comment #3)
> > Currently, this is quite conservative. Analysis of any function is suspended
> > if a function call with unresolved return type is encountered, until this
> > return type has been resolved.
>
> Short-circuiting return type analysis to "void" if there are no return
> statements in the body seems like a reasonable way to solve this particular
> case to me.
The compiler does not know whether there are any return statements in the body when starting the analysis of a function because of conditional compilation and string mixins.
Comment #7 by dlang-bugzilla — 2017-07-03T12:12:38Z
(In reply to timon.gehr from comment #6)
> The compiler does not know whether there are any return statements in the
> body when starting the analysis of a function because of conditional
> compilation and string mixins.
Are you saying that the compiler knows that a calls b, but doesn't know that a doesn't have any return statements?
Comment #8 by timon.gehr — 2017-07-03T13:14:00Z
(In reply to Vladimir Panteleev from comment #7)
> (In reply to timon.gehr from comment #6)
> > The compiler does not know whether there are any return statements in the
> > body when starting the analysis of a function because of conditional
> > compilation and string mixins.
>
> Are you saying that the compiler knows that a calls b, but doesn't know that
> a doesn't have any return statements?
What I'm saying is that you cannot short-circuit semantic analysis of function bodies based on unknown information. How would the compiler determine that there are no return statements in a's body?
E.g.:
auto a(){ auto y = b(); mixin(foo(y)); } // whether a returns depends on the return type of b.
Comment #9 by dlang-bugzilla — 2017-07-03T13:16:09Z
(In reply to timon.gehr from comment #8)
> What I'm saying is that you cannot short-circuit semantic analysis of
> function bodies based on unknown information. How would the compiler
> determine that there are no return statements in a's body?
In the general case, yes. I was talking about this particular case, as I've said above.
Comment #10 by dlang-bugzilla — 2020-11-24T05:41:44Z
(In reply to timon.gehr from comment #6)
> The compiler does not know whether there are any return statements in the
> body when starting the analysis of a function because of conditional
> compilation and string mixins.
Um, does the compiler reuse this information across instantiations of the same function template with different template parameters? See issue 21419.
Comment #11 by razvan.nitu1305 — 2023-01-04T13:58:55Z
I would vote to close this as a WONTFIX. Yeah, this simple case could be fixed by adding a special case, but as Timon mentioned it's really hard to correctly implement the general case.
Comment #12 by robert.schadek — 2024-12-13T18:10:11Z