Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph  wrote:

> I’m not sure if it’s a bug or not so I’ll wait for the compiler teams
> response and I don’t care either way, I just want constref to work. :)
>

I looked into this some more, and it's almost certainly completely
intentional behavior as Delphi does exactly the same thing for all of it.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Another benefit of pure functions

2019-07-09 Thread J. Gareth Moreton 
This is for my own benefit and note-taking, but I've just found another 
use for pure functions.


Though this is not exactly how the compiler source is structured, you 
get situations such as this.


RegName := debug_regname(taicpu(p).oper[0]^.reg); { 32-bit register name }
DebugMsg(SPeepholeOptimization + PreMessage + RegName + ',' + RegName + 
' (removes REX prefix)', p);


When not in debug mode, DebugMsg is just a null procedure that does 
nothing (as is debug_regname, but let's ignore that for the moment).


One of the definitions of pure functions is that it has no side-effects, 
so if it can be shown that RegName is not used after its assignment, and 
a pure function is being used to assign said value, then the entire call 
can be safely removed, since it won't affect any other part of the program.


If anyone is able to notice potential areas where pure functions can 
optimise a program, sound off!


Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 5:40 PM Ryan Joseph  wrote:

> I just want constref to work. :)
>

Pretty sure taking "vs_constref" out of the set here in defcmp.pas

would
do it.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 5:32 PM, Ben Grasset  wrote:
> 
> I don't know if I completely agree with this part in a general sense. There's 
> plenty of perfectly valid uses for properties that are nothing like the 
> straightforward "make something act like an array" stuff:
> 

I guess I could see people using var/out for this:

if b[v] then
  v.doSomething;

I’m not sure if it’s a bug or not so I’ll wait for the compiler teams response 
and I don’t care either way, I just want constref to work. :)

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 4:18 PM Ryan Joseph  wrote:

> it goes against the idea of properties anyways.
>

I don't know if I completely agree with this part in a general sense.
There's plenty of perfectly valid uses for properties that are nothing like
the straightforward "make something act like an array" stuff:

program Example;

{$mode Delphi}

uses SysUtils;

type
  StringGetter = function: String;
  function my: String; begin Exit('my'); end;
  function favorite: String; begin Exit('favorite'); end;
  function color: String; begin Exit('color'); end;
  function &is: String; begin Exit('is'); end;
  function red: String; begin Exit('red'); end;
  function green: String; begin Exit('green'); end;
  function blue: String; begin Exit('blue'); end;

type
  SentenceBuilder = record
  strict private
class function GetSentence(constref A: array of StringGetter): String;
static;
  public
class property Sentence[constref A: array of StringGetter]: String read
GetSentence; default;
  end;

  class function SentenceBuilder.GetSentence(constref A: array of
StringGetter): String;
  var Fn: StringGetter;
  begin
Result := '';
for Fn in A do Result := Result + Fn() + ' ';
Result := Result.TrimRight() + '.';
Result[1] := UpCase(Result[1]);
  end;

begin
  WriteLn(SentenceBuilder[[
My,
favorite,
color,
&is,
red
  ]]);
  WriteLn(SentenceBuilder[[
Blue,
&is,
my,
favorite,
color
  ]]);
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 4:09 PM, Ben Grasset  wrote:
> 
> I don't know if it necessarily *is* a bug. 
> 
> It would definitely be if it worked with literals as input, which is the 
> impression I had based on what someone reported previously for some reason, 
> but again, after testing it myself that is not the case.
> 

Yeah that doesn’t make any sense to me and it goes against the idea of 
properties anyways. To the compiler team, is this a bug? If it is I will make a 
report along with setters not allowing constref.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 3:17 PM Ryan Joseph  wrote:

> Please post an example of the var/out bug if you don’t mind. Just to be
> sure.
>

I don't know if it necessarily *is* a bug.

It would definitely be if it worked with literals as input, which is the
impression I had based on what someone reported previously for some reason,
but again, after testing it myself that is not the case.

program Example;

{$mode ObjFPC}
{$modeswitch AdvancedRecords}

type
  TRecord = record
  private
function GetBoolOut(out Index: PtrUInt): Boolean;
function GetBoolVar(var Index: PtrUInt): Boolean;
  public
property OutBools[out Index: PtrUInt]: Boolean read GetBoolOut;
property VarBools[var Index: PtrUInt]: Boolean read GetBoolVar;
  end;

  function TRecord.GetBoolOut(out Index: PtrUInt): Boolean;
  begin
Result := Index > 5000;
  end;

  function TRecord.GetBoolVar(var Index: PtrUInt): Boolean;
  begin
Result := Index > 5000;
  end;

var
  R: TRecord;
  I: PtrUInt = 5000;

begin
  // Error: Variable identifier expected
  WriteLn(R.OutBools[5001]);
  // Error: Variable identifier expected
  WriteLn(R.VarBools[5001]);
  // Works fine
  WriteLn(R.OutBools[I]);
  // Works fine
  WriteLn(R.VarBools[I]);
end.

So the behavior as far as making sense based on the definition of "out" and
"var" is correct. The only thing that's really "strange" to me is the fact
that getters are completely unrestricted in that regard, while setters
explicitly need {$VARPROPSETTER ON}.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.4 ld error on opensuse 13.2

2019-07-09 Thread Florian Klämpfl 
Am 09.07.2019 um 19:46 schrieb Nikolai Zhubr:
> Hi all,
> 
> I've just discovered fpc-3.0.4-1.x86_64.rpm does not quite work on opensuse 
> 13.2. That is, linking helloworld fails with:
> 
> fpc hello.pas
> Free Pascal Compiler version 3.0.4 [2017/10/02] for x86_64
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target OS: Linux for x86-64
> Compiling hello.pas
> Linking hello
> /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
> /usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/prt0.o: unrecognized 
> relocation (0x2a) in section `.text'
> /usr/bin/ld: final link failed: Bad value
> hello.pas(7,1) Error: Error while linking
> hello.pas(7,1) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> Error: /usr/bin/ppcx64 returned an error exitcode
> 
> Meanwhile, fpc-2.6.4-1.x86_64.rpm does work fine.
> 
> /usr/bin/ld --version
> GNU ld (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1
> 
> Of course this ld is pretty old, so my first thought was that I need some 
> newer binutils. However, I've found
> fpcbuild-3.0.4.zip contains 2.22 version (for windows, but anyway), and also 
> on windows I use cross-binutils 2.16 and
> 2.31 (and they work fine and produce perfectly valid linux-i386 and linux-arm 
> executables), so now I'm somewhat confused
> about what to do next. AFAICS docs does not explicitely mention any 
> particular binutils requirement. I could
> repackage/patch/replace stock binutils package, but because I don't 
> understand the exact reason for the error, I thought
> I'd ask for advice first.

As windows uses a different binary format, it is not possible to judge from 
windows to linux. I am pretty convinced, a
newer ld might help.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-09 Thread J. Gareth Moreton 
Hopefully we'll get there in the end!  I've updated what I can in the 
patch file directly, so hopefully all is well now.


Some of the variable names, like "ProcName", were already named as such.

Gareth aka. Kit

On 09/07/2019 10:12, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Di., 9. Juli 2019, 08:20:


Apologies - I see now... I used them with "with" without even
thinking
about it!  I've made the changes as requested. Admittedly it's quite
hard for me to remove spaces from either side of operators because
that's something I learnt from my early days in Turbo Pascal and
to not
have spaces (and all types and variables being lowercase) feels very
C-like.  But hey, rules are rules... or guidelines!


I know the feeling. But when in Rome...

Is the new AS-IS-enum-08 patch any better?


Better (though are still some " = " around :P ), but it seems you 
missed tasnode.pass_1?
Also the typenames (TOrdDef, TEnumDef) should be lowercase as well as 
the local variables.


Regards,
Sven


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 3:15 PM, Ben Grasset  wrote:
> 
> Well, they *are* accepted for things that would normally be valid with "var" 
> and "out" in other scenarios (by which I mean, variables, not numeric 
> literals / e.t.c) 

Please post an example of the var/out bug if you don’t mind. Just to be sure.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 2:58 PM Ryan Joseph  wrote:

> Ok, I'm confused now. I thought that var/out were accepted but I just
> tested myself and indeed they are rejected.
>

Well, they *are* accepted for things that would normally be valid with
"var" and "out" in other scenarios (by which I mean, variables, not numeric
literals / e.t.c)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 12:59 PM, Ben Grasset  wrote:
> 
> Well, I just checked, and with "out" and "var" for a getter with an array 
> property it actually doesn't compile if you pass a literal. Which is good as 
> at least it behaves logically.
> 
> That said, I'm unsure why setters need a directive, but getters do not. (Even 
> constref works fine, with no directives, currently, for getters.)
> 

Ok, I'm confused now. I thought that var/out were accepted but I just tested 
myself and indeed they are rejected. As for the directive I understand that’s 
just a calling convention change for compatibility with other systems.

That means the only bug I’m interested in is allowing array property setters to 
use constref.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] FPC 3.0.4 ld error on opensuse 13.2

2019-07-09 Thread Nikolai Zhubr 

Hi all,

I've just discovered fpc-3.0.4-1.x86_64.rpm does not quite work on 
opensuse 13.2. That is, linking helloworld fails with:


fpc hello.pas
Free Pascal Compiler version 3.0.4 [2017/10/02] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling hello.pas
Linking hello
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
/usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/prt0.o: 
unrecognized relocation (0x2a) in section `.text'

/usr/bin/ld: final link failed: Bad value
hello.pas(7,1) Error: Error while linking
hello.pas(7,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode

Meanwhile, fpc-2.6.4-1.x86_64.rpm does work fine.

/usr/bin/ld --version
GNU ld (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1

Of course this ld is pretty old, so my first thought was that I need 
some newer binutils. However, I've found fpcbuild-3.0.4.zip contains 
2.22 version (for windows, but anyway), and also on windows I use 
cross-binutils 2.16 and 2.31 (and they work fine and produce perfectly 
valid linux-i386 and linux-arm executables), so now I'm somewhat 
confused about what to do next. AFAICS docs does not explicitely mention 
any particular binutils requirement. I could repackage/patch/replace 
stock binutils package, but because I don't understand the exact reason 
for the error, I thought I'd ask for advice first.


Thank you,

Regards,
Nikolai

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 12:59 PM Ben Grasset  wrote:

> On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph  wrote:
>
>> So do I need to open another bug report for for this out/var/constref
>> stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but
>> that’s just about the overloading bugs.
>>
>> I think it needs to be something like var/out should be be blocked in
>> properties (unless VARPROPSETTER is on?) and constref should be allowed.
>> Please confirm if that’s correct and I’ll make another bug report.
>>
>
> - snip -
>

Also, the {$VARPROPSETTER} docs should be amended to not say "const",
because again, "const" is allowed in all circumstances and does not
guarantee by-reference passing the way "var", "out", and "constref" do.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 12:32 PM Ryan Joseph  wrote:

> So do I need to open another bug report for for this out/var/constref
> stuff? We already have https://bugs.freepascal.org/view.php?id=28949 but
> that’s just about the overloading bugs.
>
> I think it needs to be something like var/out should be be blocked in
> properties (unless VARPROPSETTER is on?) and constref should be allowed.
> Please confirm if that’s correct and I’ll make another bug report.
>

Well, I just checked, and with "out" and "var" for a getter with an array
property it actually doesn't compile if you pass a literal. Which is good
as at least it behaves logically.

That said, I'm unsure why setters need a directive, but getters do not.
(Even constref works fine, with no directives, currently, for getters.)

If anything, what would make the most sense is to just have a {$VARPROP}
directive that enabled all of the "by reference" stuff for both getters
*and* setters, while otherwise restricting them both to only "const",
"constref", or "unprefixed" parameters.

{$VARPROPSETTER} presumably needs to also be left as-is for Delphi
compatibility, but that's not really a big deal either way.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 12:28 PM, Ben Grasset  wrote:
> 
> As far as the "out", I'd say that is a lexical/parser bug certainly, although 
> it does not seem to actually *behave* like "out" in the case of something like
> 

So do I need to open another bug report for for this out/var/constref stuff? We 
already have https://bugs.freepascal.org/view.php?id=28949 but that’s just 
about the overloading bugs. 

I think it needs to be something like var/out should be be blocked in 
properties (unless VARPROPSETTER is on?) and constref should be allowed. Please 
confirm if that’s correct and I’ll make another bug report.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 12:11 PM Ryan Joseph  wrote:

> Why does that require a special switch? Also, I thought it was determined
> that allowed “out” in array properties was a bug?
>

Not sure about the exact history of VARPROPSETTER. It's an old Delphi
thing, rarely used nowadays though.

As far as the "out", I'd say that is a lexical/parser bug certainly,
although it does not seem to actually *behave* like "out" in the case of
something like

function GetThing(out I: PtrUInt): TThing;
property Thing[out I: PtrUInt]: TThing read GetThing;

as if it did it couldn't possibly compile with a PtrUInt literal like
"MyThing := BlahBlah.Thing[27]". The compiler seems to just act as though
it was "var" there.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 


> On Jul 9, 2019, at 12:09 PM, Ben Grasset  wrote:
> 
> It works for constref if you use {$VARPROPSETTER ON}.
> 
> The docs for that directive are slightly incorrect, I just noticed, also:
> 
> https://www.freepascal.org/docs-html/current/prog/progsu121.html
> Where it says "Enable use of var/out/const parameters for property setters", 
> it should say "Enable use of var/out/constref parameters for property 
> setters", because "const" is always allowed, and does not *guarantee* 
> by-reference passing the way "constref" does.
> 

Why does that require a special switch? Also, I thought it was determined that 
allowed “out” in array properties was a bug?

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ben Grasset 
On Tue, Jul 9, 2019 at 9:39 AM Ryan Joseph  wrote:

> Another thing regarding array properties. If I use constref on the setter
> I get an error "Illegal symbol for property access”. Is there any reason
> why the setter can’t be constref?
>

It works for constref if you use {$VARPROPSETTER ON}.

The docs for that directive are slightly incorrect, I just noticed, also:

https://www.freepascal.org/docs-html/current/prog/progsu121.html
Where it says "Enable use of var/out/const parameters for property
setters", it should say "Enable use of var/out/constref parameters for
property setters", because "const" is always allowed, and does not
*guarantee* by-reference passing the way "constref" does.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Sven Barth via fpc-devel 
Ryan Joseph  schrieb am Di., 9. Juli 2019, 15:39:

> Another thing regarding array properties. If I use constref on the setter
> I get an error "Illegal symbol for property access”. Is there any reason
> why the setter can’t be constref? If not I’d like to change this with my
> array properties patch. Making it inline properly avoids the copy but you
> may not want inline and just want to avoid the copy during setting.


It was probably an oversight when constref was introduced.

I wouldn't stuff everything and the kitchen sink into your overload patch
however. This and the fix regarding signature checks might be interesting
to merge into 3.2 while property overloads might have to "mature" a bit
inside trunk.

Regards,
Sven

>
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

2019-07-09 Thread Ryan Joseph 
Another thing regarding array properties. If I use constref on the setter I get 
an error "Illegal symbol for property access”. Is there any reason why the 
setter can’t be constref? If not I’d like to change this with my array 
properties patch. Making it inline properly avoids the copy but you may not 
want inline and just want to avoid the copy during setting.

 function GetValue(index: integer): T; inline;
 procedure SetValue(index: integer; constref value: T); inline; // “T” is a 
record so we want constref here
 property PrivateValues[index: integer]: T read GetValue write SetValue; 
default; // ERROR: Illegal symbol for property access

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

2019-07-09 Thread Ryan Joseph 


> On Jul 8, 2019, at 9:56 PM, Ben Grasset  wrote:
> 
> So, that said, my Github fork branch of the compiler now contains a 
> {$MultiLineStringTrimLeft} directive, that does precisely what you might 
> think. Here's one of my compiler tests, which I think demonstrates it fairly 
> well:
> 

Excellent, now everyone is happy.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-09 Thread Sven Barth via fpc-devel 
J. Gareth Moreton  schrieb am Di., 9. Juli 2019,
08:20:

> Apologies - I see now... I used them with "with" without even thinking
> about it!  I've made the changes as requested. Admittedly it's quite
> hard for me to remove spaces from either side of operators because
> that's something I learnt from my early days in Turbo Pascal and to not
> have spaces (and all types and variables being lowercase) feels very
> C-like.  But hey, rules are rules... or guidelines!
>

I know the feeling. But when in Rome...

Is the new AS-IS-enum-08 patch any better?
>

Better (though are still some " = " around :P ), but it seems you missed
tasnode.pass_1?
Also the typenames (TOrdDef, TEnumDef) should be lowercase as well as the
local variables.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel