Project

General

Profile

Bug #2060

forward function definitions that include a parameter name can "fixup" missing parameter names in the actual definition (avoiding a 4GL compiler error)

Added by Greg Shah about 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
02/26/2013
Due date:
% Done:

0%

Estimated time:
3.00 h
billable:
No
vendor_id:
GCD
case_num:

ges_upd20130226c.zip (4.95 KB) Greg Shah, 02/26/2013 04:15 PM

History

#1 Updated by Greg Shah about 11 years ago

In #1985 (see notes 29, 36 - 43 in that task) we found that forward function definitions that include a parameter name can "fixup" missing parameter names in the actual definition (avoiding a 4GL compiler error).

This testcase:

function aaa returns char (buffer for book):
end.

shows this compile-time error in the 4GL:

Need a name for argument number 1 of function, method, or class event 'funcname'. (5632)

BUT, this testcase does not fail in the 4GL:

function func0 returns int(buffer bb for book) in super.
function func0 returns int(buffer for book). end.

message this-procedure:get-signature("func0"). /* shows "bb" */

#2 Updated by Greg Shah about 11 years ago

I tested various combinations of other parameter types:

- the regular AS "primitive" types (CHAR, INT, LOGICAL...)
- TABLE tablename
- TABLE-HANDLE handlename

None of these exhibit this "special" behavior like the BUFFER FOR TABLE case. You simply cannot leave these names off the "real" definition of the function. The same findings were made for FORWARD, IN handle and IN SUPER. The parameter mode also seemed to have no effect, although I did not try every combination of mode with every type.

I did not test AS CLASS, DATASET or DATASET-HANDLE.

#3 Updated by Greg Shah about 11 years ago

Attached is the update that resolves this issue. It will duplicate the non-forward function definition's buffer parameter's symbol node when it is missing if and only if there is a matching forward declaration where the corresponding buffer is named. It is going through conversion regression testing now.

#4 Updated by Greg Shah about 11 years ago

Passed conversion and is checked into bzr as revision 10216.

#5 Updated by Greg Shah about 11 years ago

  • Status changed from WIP to Closed

#6 Updated by Greg Shah over 7 years ago

  • Target version changed from Milestone 4 to Conversion Support for Server Features

Also available in: Atom PDF