After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 574403 - direction of formal parameters in Signal delegates are ignored.
direction of formal parameters in Signal delegates are ignored.
Status: RESOLVED DUPLICATE of bug 622570
Product: vala
Classification: Core
Component: Methods
unspecified
Other All
: Normal critical
: 1.2
Assigned To: Jürg Billeter
Vala maintainers
: 583482 (view as bug list)
Depends on:
Blocks: 571685
 
 
Reported: 2009-03-06 18:08 UTC by rainwoodman
Modified: 2017-12-13 19:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix-bug-574403-direction-of-formal-parameters-in (1017 bytes, patch)
2009-03-06 18:57 UTC, rainwoodman
committed Details | Review
Fix the missing direction in the lambda function itself. (3.84 KB, patch)
2009-05-09 23:51 UTC, rainwoodman
reviewed Details | Review

Description rainwoodman 2009-03-06 18:08:17 UTC
Please describe the problem:
consider a signal declared as

signal void event(ref bool some_value);

if a lambda is connected to event with
obj.event += (_obj, some_value) => {
/*play with the _obj*/

}

some_value is treated as bool instead of ref bool.


Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 rainwoodman 2009-03-06 18:19:42 UTC
No. Actually the problem lies in the signal wrapper functions.
Even if the signal handler is a regular function, the ref and out modifiers are also silently discarded. This is very dangerous!
Comment 2 rainwoodman 2009-03-06 18:56:22 UTC
The actual cause of the problem is that the direction of formal parameters in Signal delegates are ignored.

I am working on a fix.
Comment 3 rainwoodman 2009-03-06 18:57:54 UTC
Created attachment 130211 [details] [review]
Fix-bug-574403-direction-of-formal-parameters-in

GIT rocks!
Comment 4 rainwoodman 2009-03-23 02:04:12 UTC
The patch is merged to Bug 571685.
Comment 5 Jürg Billeter 2009-03-26 10:02:09 UTC
commit bbad7d44826b5ae517fcc61c91427372eefef903
Author: Feng Yu <fengyu@dhcp5-240.iucf.indiana.edu>
Date:   Fri Mar 6 13:55:00 2009 -0500

    Bug 574403: Direction of formal parameters ignored
    
    When copying a formal parameter, the direction should also be copied.
    This fix might also fix other bizarre issues related to copying formal
    parameters.
Comment 6 rainwoodman 2009-04-13 20:44:55 UTC
Still have problems on 0.6.1. 
Although the marshaller respects the direction,
the anonymous lambda function still ignores it.
Comment 7 rainwoodman 2009-05-09 23:51:29 UTC
Created attachment 134336 [details] [review]
Fix the missing direction in the lambda function itself.

Although the direction was passed to the wrappers of the lambda functions, they are still missing in lambda itself.

This follow-up patch completely fixes the problem.
Comment 8 Mike Massonnet 2009-05-23 09:44:26 UTC
*** Bug 583482 has been marked as a duplicate of this bug. ***
Comment 9 Jürg Billeter 2009-05-25 19:00:07 UTC
We shouldn't allow implicit output parameters, i.e., I think we should require the `out' modifier also for parameters in lambda expression.
Comment 10 rainwoodman 2009-05-26 02:16:47 UTC
So the parser has to be patched to accept the modifier in lambdas?

Comment 11 Jürg Billeter 2009-05-26 07:14:24 UTC
Yes, this requires a parser change.
Comment 12 rainwoodman 2009-06-25 08:27:10 UTC
More than a parser change.

Vala.LambdaExpression stores parameters as string. There is no place for the direction information, unless one make changes in valalambdaexpression.vala.

I propose to add a new type 

class Vala.LambdaParameter : Symbol {
/* the name of the parameter */
  public string name;
/* the direction */
  public ParameterDirection direction;
/* non-null if a type is specificly mentioned in the lambda*/
  public DataType? parameter_type;
}

and corresponding Vala.Parser.parse_lambda_parameter

Comment 13 Jürg Billeter 2009-07-28 14:48:47 UTC
Is there a reason why we can't just reuse FormalParameter?
Comment 14 rainwoodman 2009-07-29 10:05:27 UTC
Two reasons:

1 In FormalParameter the type field is mandatory, not true for a lambda parameter.
If we reuse FormalParameter, the parser for FormalParameter has to be changed to add a context dependent mode. That's risking changing the gramma of the language. 
It is safer+easier to add a new type and a new parser in this case.

2 parameters in lambdas are fundamentally different from formal parameters: they are always converted to a formal parameter by the semantic analyzer(if I remember correctly).

Comment 15 Jürg Billeter 2009-09-17 15:54:19 UTC
Even though there are a couple differences between method/delegate parameters and lambda parameters, they essentially have the same purpose. The parameter_type property in FormalParameter is also optional, although at the moment only in the ellipsis case.

We can still have a separate parsing function if we think it's easier than adding a parameter to the existing formal parameter parsing function (to denote whether types are optional or required).
Comment 16 Daniel Espinosa 2017-02-17 20:09:51 UTC
May this issue can be worked on for milestone 1.2
Comment 17 Rico Tzschichholz 2017-12-13 19:22:35 UTC

*** This bug has been marked as a duplicate of bug 622570 ***