Re: [fpc-devel] Procedural types returning file types
Blaise--- via fpc-devel schrieb am Fr., 18. Dez. 2020, 10:01: > The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) > fixes the following: > ---8<--- > // EXPECTED: 'Error: Illegal function result type' > // ACTUAL: gets compiled > type M = function : file; > > begin > end. > ---8<--- > Applied in 47810 with the change of the def parameter of single_type in a separate commit (47809). Thanks. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Procedural types returning file types
On 2020-12-18 14:06, Sven Barth wrote: Tomas Hajny via fpc-devel schrieb am Fr., 18. Dez. 2020, 11:38: On 2020-12-18 10:01, Blaise--- via fpc-devel wrote: Hello, > The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) > fixes the following: > ---8<--- > // EXPECTED: 'Error: Illegal function result type' > // ACTUAL: gets compiled > type M = function : file; > > begin > end. > ---8<--- Sorry for a silly question, but conceptually - why a file (which is technically a record) shouldn't be allowed if records are allowed and the result (i.e. the file) may be assigned to another variable of the type file? Do you have any information why the compiled functionality wouldn't work correctly? Because TP and Delphi don't allow it either. In fact FPC doesn't allow it as well for function declarations, but for function and method variables a different code path is used. I see. IIRC at least TP doesn't allow records as return types and using records in assignments either whereas FPC does. However, the reasons for disallowing file there may be actually related to the second part of your response below. Sidenote: it also isn't allowed to pass file type parameters by value (the compiler checks this) which is why you always see them with "var" or "const". Ah, yes, that indeed has the same reason for which a file shouldn't be allowed for return value, thanks for reminding me of this. I believe that this is already explicitly specified in the original Pascal definition. The reasons are probably conceptual - semantically, 'file' in Pascal doesn't mean a record containing some file descriptor and other information necessary for working with the file, but the content of the file. From this point of view, you could indeed never pass a file by value or return it as a return value. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Procedural types returning file types
Tomas Hajny via fpc-devel schrieb am Fr., 18. Dez. 2020, 11:38: > On 2020-12-18 10:01, Blaise--- via fpc-devel wrote: > > > Hello, > > > The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) > > fixes the following: > > ---8<--- > > // EXPECTED: 'Error: Illegal function result type' > > // ACTUAL: gets compiled > > type M = function : file; > > > > begin > > end. > > ---8<--- > > Sorry for a silly question, but conceptually - why a file (which is > technically a record) shouldn't be allowed if records are allowed and > the result (i.e. the file) may be assigned to another variable of the > type file? Do you have any information why the compiled functionality > wouldn't work correctly? > Because TP and Delphi don't allow it either. In fact FPC doesn't allow it as well for function declarations, but for function and method variables a different code path is used. Sidenote: it also isn't allowed to pass file type parameters by value (the compiler checks this) which is why you always see them with "var" or "const". Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Procedural types returning file types
On 2020-12-18 10:01, Blaise--- via fpc-devel wrote: Hello, The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) fixes the following: ---8<--- // EXPECTED: 'Error: Illegal function result type' // ACTUAL: gets compiled type M = function : file; begin end. ---8<--- Sorry for a silly question, but conceptually - why a file (which is technically a record) shouldn't be allowed if records are allowed and the result (i.e. the file) may be assigned to another variable of the type file? Do you have any information why the compiled functionality wouldn't work correctly? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Procedural types returning file types
The patch http://hg.blaise.ru/public/fpc/rev/698389953e49 (attached) fixes the
following:
---8<---
// EXPECTED: 'Error: Illegal function result type'
// ACTUAL: gets compiled
type M = function : file;
begin
end.
---8<---
--
βþ
# HG changeset patch
# User Blaise.ru
# Date 1608281477 -10800
! procvar_dec: reject file types as result types of procedural types
diff -r a4ade871efd2 -r ac2ef7649638 pdecsub.pas
--- a/pdecsub.pas Thu Dec 17 10:58:01 2020 +0300
+++ b/pdecsub.pas Fri Dec 18 11:51:17 2020 +0300
@@ -1344,7 +1344,7 @@
parse_generic:=(df_generic in pd.defoptions);
if pd.is_generic or pd.is_specialization then
symtablestack.push(pd.parast);
-single_type(pd.returndef,[stoAllowSpecialization]);
+pd.returndef:=result_type([stoAllowSpecialization]);
// Issue #24863, enabled only for the main progra commented out
for now because it breaks building of RTL and needs extensive
// testing and/or RTL patching.
@@ -1555,10 +1555,6 @@
include(pd.procoptions,po_variadic);
end;
-{ file types can't be function results }
-if assigned(pd) and
- (pd.returndef.typ=filedef) then
- message(parser_e_illegal_function_result);
{ support procedure proc stdcall export; }
if not(check_proc_directive(false)) then
begin
diff -r a4ade871efd2 -r ac2ef7649638 ptype.pas
--- a/ptype.pas Thu Dec 17 10:58:01 2020 +0300
+++ b/ptype.pas Fri Dec 18 11:51:17 2020 +0300
@@ -41,7 +41,9 @@
procedure resolve_forward_types;
{ reads a string, file type or a type identifier }
-procedure single_type(var def:tdef;options:TSingleTypeOptions);
+procedure single_type(out def:tdef;options:TSingleTypeOptions);
+{ ... but rejects types that cannot be returned from functions }
+function result_type(options:TSingleTypeOptions):tdef;
{ reads any type declaration, where the resulting type will get name as
type identifier }
procedure read_named_type(var def:tdef;const
newsym:tsym;genericdef:tstoreddef;genericlist:tfphashobjectlist;parseprocvardir:boolean;var
hadtypetoken:boolean);
@@ -454,7 +456,7 @@
end;
-procedure single_type(var def:tdef;options:TSingleTypeOptions);
+procedure single_type(out def:tdef;options:TSingleTypeOptions);
var
t2 : tdef;
isspecialize,
@@ -645,6 +647,14 @@
end;
+function result_type(options:TSingleTypeOptions):tdef;
+ begin
+single_type(result,options);
+{ file types cannot be function results }
+if result.typ=filedef then
+ message(parser_e_illegal_function_result);
+ end;
+
procedure parse_record_members(recsym:tsym);
function IsAnonOrLocal: Boolean;
@@ -1587,7 +1597,7 @@
if is_func then
begin
consume(_COLON);
-single_type(pd.returndef,[stoAllowSpecialization]);
+pd.returndef:=result_type([stoAllowSpecialization]);
end;
if try_to_consume(_OF) then
begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
