The latter one is already reported and I seem to remember it has been fixed in fpc main.I did complain about it once, see #37547 (https://gitlab.com/freepascal.org/fpc/source/-/issues/37547). It was marked as a duplicate of #32994 (https://gitlab.com/freepascal.org/fpc/source/-/issues/32994) which is still open.
function A() : integer;
var
Avar : qword - 0; { is this supposed to compile ??? }
and then what about 16-bit "word + 0" or "int16 + 0" or "smallint + 0"?
Q.E.D.
My guess is this is because CPU register size. I am compiling in Win64, so int64/qword is okayAnd how that relates to the FPC parser? Because (AFAIK) it is an incorrect syntax at the first place.
As long it evaluates to zero
дали детям игрушку :-DExactly.
And I very much wonder what an expression has to do where a type non-terminal was expected. :o
I won't dig in the compiler sources. At least not for that.And I very much wonder what an expression has to do where a type non-terminal was expected. :o
if you really do it "very much" - there are soruces.
I do not, though. Not THAT much.
Known is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC).
It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined.
I wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams (https://www.freepascal.org/docs-html/ref/refli5.html) are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written.Known is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC).
It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined.
FPC's parser is not derived from a grammar, but it's a hand written one.
In this case the “problem” is that the type expression for e.g. a variable or a field is done using the same function that parses a normal expression just set to a different mode (namely “parse type” instead of “parse normal body”) - this is done because the two share quite some functionality - , but for some reason it doesn't correctly filter out expressions that shouldn't be part of a type expression.As you confirm, and also as Arioch speculated, the parser parts for <type> and <expression> somehow intertwined here. And I wonder how one can find enough similarities between the two and put them in one function.
I wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams (https://www.freepascal.org/docs-html/ref/refli5.html) are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written.
I wouldn't agree with that. Every formal language have a formal grammar. Syntax diagrams (https://www.freepascal.org/docs-html/ref/refli5.html) are just other representation of the metalanguage such as BNF. So the parser should be implemented strictly according to (deriving from) that grammar, even it was hand written.Known is that the Pascal is (at least was) a LL(1) grammar, the compiler implements a recursive descent parser and that is the foundation of its lightning speed. BTW it is still advertised as such (FPC).
It seems that has changed, IMO the RDP is not capable of such a flippant behavior. This is a direct violation of the syntax as it was defined.
FPC's parser is not derived from a grammar, but it's a hand written one.
In this case the “problem” is that the type expression for e.g. a variable or a field is done using the same function that parses a normal expression just set to a different mode (namely “parse type” instead of “parse normal body”) - this is done because the two share quite some functionality - , but for some reason it doesn't correctly filter out expressions that shouldn't be part of a type expression.As you confirm, and also as Arioch speculated, the parser parts for <type> and <expression> somehow intertwined here. And I wonder how one can find enough similarities between the two and put them in one function.
P.S.
Despite the sub-range was defined in https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-290003.1.1 as:it is more like:
There never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands).
*snip*Not sure the RDP can handle it without back-tracking ... I have tried this on D7 - it fails in the similar way as FPC. Perhaps we can say they're compatible in the way they fail. ;)P.S.
Despite the sub-range was defined in https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-290003.1.1 as:it is more like:
These should probably be reported then...
@PascalDragon
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
Reference: appendix A of the Delphi language guide for D7.
I am a bit bemused you are not aware of that? ;)
@PascalDragon
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
You can't build a compiler from that.Actually you CAN! But only partially conformant to the actual release Delphi compilers.
MarkMLl
That grammar was used internally too and not just for documentation.
@PascalDragonUnfortunately not a proper BNF. See e.g.
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
Reference: appendix A of the Delphi language guide for D7.
I am a bit bemused you are not aware of that? ;)
( At that time, though, most proper Elvises had left the building(s))
@PascalDragon
There was a formal grammar published by Borland. (D5-D7) in BNR notation and that was not a refactoring or a back-port. It was the real deal. I did some work for Borland att.
It was only partially correct though, but neigh complete. And it served many purposes and still does. Sloppy engineering.
Reference: appendix A of the Delphi language guide for D7.
I am a bit bemused you are not aware of that? ;)
There never was a formal grammar we began with. And the syntax diagrams that exist are derived from what the compiler supports (and even then some are faulty, because the one writing the documentation didn't find out everything that the compiler itself understands).
Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals).
What did I skip? Other way around! Yes, there was the grammar included in the TP manuals, but that does not mean that it was used. (And the syntax diagrams is a reference to our own manuals).Not TP but D5-D7, and that WAS used. I was there, you know that. I may have forgotten that: Borland used almost always internal tools, also for their flavor of BNF.