[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #11 from RazvanN  ---
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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #10 from Vladimir Panteleev  ---
(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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

--- Comment #9 from Vladimir Panteleev  ---
(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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

--- Comment #8 from timon.g...@gmx.ch ---
(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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #7 from Vladimir Panteleev  ---
(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?

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

--- Comment #6 from timon.g...@gmx.ch ---
(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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(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.

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

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

Stewart Gordon s...@iname.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||s...@iname.com

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10810


timon.g...@gmx.ch changed:

   What|Removed |Added

 CC||timon.g...@gmx.ch


--- Comment #1 from timon.g...@gmx.ch 2013-08-12 13:07:40 PDT ---
I think this is expected behaviour and this issue is an enhancement.

Exactly which additional cases do you want to make work?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10810



--- Comment #2 from Henning Pohl henn...@still-hidden.de 2013-08-12 16:44:06 
PDT ---
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(); }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10810



--- Comment #3 from timon.g...@gmx.ch 2013-08-12 19:01:18 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---