GNOME Bugzilla – Bug 574403
direction of formal parameters in Signal delegates are ignored.
Last modified: 2017-12-13 19:22:35 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:
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!
The actual cause of the problem is that the direction of formal parameters in Signal delegates are ignored. I am working on a fix.
Created attachment 130211 [details] [review] Fix-bug-574403-direction-of-formal-parameters-in GIT rocks!
The patch is merged to Bug 571685.
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.
Still have problems on 0.6.1. Although the marshaller respects the direction, the anonymous lambda function still ignores it.
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.
*** Bug 583482 has been marked as a duplicate of this bug. ***
We shouldn't allow implicit output parameters, i.e., I think we should require the `out' modifier also for parameters in lambda expression.
So the parser has to be patched to accept the modifier in lambdas?
Yes, this requires a parser change.
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
Is there a reason why we can't just reuse FormalParameter?
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).
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).
May this issue can be worked on for milestone 1.2
*** This bug has been marked as a duplicate of bug 622570 ***