Re: [fpc-devel] Fwd: Re: An optimization suggestion for FPC

J. Gareth Moreton schrieb am Mo., 13. Juli 2020, 12:23: > I haven't been able to test it as rigorously as I would have liked. I'm > having some difficulty compiling projects under Lazarus with the trunk > since it tries to recompile windows.ppu due to a checksum mismatch, and > immediately

Re: [fpc-devel] just for information

Am 12.07.2020 um 09:37 schrieb Samuel Herzog via fpc-devel: Hello List-Members, first of all thank you all for the FPC 3.2 release! I am the maintainer of sourceforge.net/projects/scimarkfordelphi/ Scimark for Delphi

Re: [fpc-devel] [fpc-announce] FPC 3.2.0 released!

Ryan Joseph via fpc-devel schrieb am Mo., 6. Juli 2020, 19:04: > > > > On Jul 4, 2020, at 8:10 PM, Marco van de Voort < > f...@pascalprogramming.org> wrote: > > > > But the syntax will be CARD(variable), and there are some minor > things wrong with it: (anyone?) > > I'm waiting on my patch for

Re: [fpc-devel] FPC and Z80

Christo Crause schrieb am Di., 23. Juni 2020, 16:37: > On Tue, Jun 23, 2020 at 3:56 PM wrote: > >> Hi FPC team. >> >> I'm trying to compile a FPC 3.2 with support to Z80/MSXDOS, for linux and >> almost everything seems to be compiling fine, because the compiler was >> generated but RTL was not.

Re: [fpc-devel] FPC and Z80

schrieb am Di., 23. Juni 2020, 15:56: > Hi FPC team. > > I'm trying to compile a FPC 3.2 with support to Z80/MSXDOS, for linux and > almost everything seems to be compiling fine, because the compiler was > generated but RTL was not. > > I'm using the same build script of zxspectrum (I just

Re: [fpc-devel] FPC and Z80

Am 23.06.2020 um 18:59 schrieb popolon...@popolony2k.com.br: Thanks a lot. Everything is working fine. I compiled my first FPC code (simple hello world)  to MSX-DOS2 and is working fine. Good to know. :) The only thing I realized, is something someone here wrote before, that is the size of

Re: [fpc-devel] FPC and Z80

PopolonY2K schrieb am Mi., 10. Juni 2020, 00:38: > Thank you. > > My library is very complete, 100% MSXBIOS, MSXDOS and MSXDOS2, Memory > mapper and several others implementations ready, but they are working just > with TP3. > > Features like Inline code are provided by FPC by using Asm/EndAsm.

Re: [fpc-devel] FPC and Z80

Am 16.04.2020 um 11:04 schrieb Guillermo: Thanks Swen. I see last commit was 2 days ago so it is active. I would like to know who is responsible to speak to him. May be I can help with the MSX target, but I need gidance about the internals of the compiler (I tried but it is beyond my

Re: [fpc-devel] FPC and Z80

PopolonY2K schrieb am Di., 9. Juni 2020, 16:03: > Thanks. > > I'll start porting all Turbo Pascal 3 library compatible, to FPC using > units. > Great! If you find any problems, please don't hesitate to report them either here or on the bugtracker at bugs.freepascal.org :) And if you have any

Re: [fpc-devel] Allow object type property getter to expose a field as one of its base/parent types (patch included)

Am 04.06.2020 um 03:45 schrieb Kostas Michalopoulos via fpc-devel: Hello, I'd like to add a small feature for property getters to allow themselves be exposed as a base type of the real field. Example: === program ExposeDerivedAsBase; {$mode objfpc} type TBase = class end; TDerived =

Re: [fpc-devel] Generic method works on Linux, not on Windows?

Am 30.05.2020 um 14:28 schrieb Sven Barth: Am 30.05.2020 um 12:33 schrieb Yuriy Sydorov: On 29.05.2020 22:36, Sven Barth via fpc-devel wrote: Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: On 27.05.2020 1:01, Joost van der Sluis wrote: Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: Does

Re: [fpc-devel] Merge request for 3.2 fixes

J. Gareth Moreton schrieb am Sa., 25. Juli 2020, 22:24: > Since 3.2.0 has already had a public release, should the version number > be incremented to 3.2.1 or some such? > The version of the fixes branch already *is* 3.2.1 since 20th June (

[fpc-devel] ROL/ROR with Carry

Hello together! Considering that jamie philbrook has given up on his feature request ( https://bugs.freepascal.org/view.php?id=38341 ) rather quickly and that it had been my idea for him to open that bug report I'd like to discuss this here. So the idea is to add support for ROL/ROR with

Re: [fpc-devel] Error: Global Generic template references static symtable

Bart via fpc-devel schrieb am Mo., 11. Jan. 2021, 03:42: > On Sun, Jan 10, 2021 at 11:59 AM Sven Barth via fpc-devel > wrote: > > > Displaying the message at the correct location would be more involved... > > you might want to open a bug report for that so that it's rem

Re: [fpc-devel] Compiler message colour scheme

Tomas Hajny via fpc-devel schrieb am Mi., 25. Nov. 2020, 13:31: > On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote: > > 25.11.2020 1:52, Tomas Hajny via fpc-devel: > > > > > Hi Nikolai, > > >> No problem, thanks for testing. Unfortunately, it doesn't work for me > >> under Windows (Win 10

Re: [fpc-devel] Compiler message colour scheme

Am 25.11.2020 um 15:44 schrieb Tomas Hajny via fpc-devel: On 2020-11-25 14:40, Sven Barth via fpc-devel wrote: Tomas Hajny via fpc-devel schrieb am Mi., 25. Nov. 2020, 13:31: On 2020-11-25 10:31, Nikolai Zhubr via fpc-devel wrote: > 25.11.2020 1:52, Tomas Hajny via fpc-devel:  .  .

Re: [fpc-devel] Different handling of try..except depending on OS?

Am 09.12.2020 um 23:45 schrieb Bart via fpc-devel: Compiled with fpc 3.2.0 on Windows it will output (both 32 and 64 bit): Runtime error 201 at $004015F1 $004015F1 $00407307 Compiled with fpc 3.2.0 on linux X86_64 it will output Except block Finally block On Windows you need to include

Re: [fpc-devel] Different handling of try..except depending on OS?

Bart via fpc-devel schrieb am Do., 10. Dez. 2020, 11:56: > On Thu, Dec 10, 2020 at 7:34 AM Sven Barth via fpc-devel > wrote: > > > That is correct, because without the SysUtils unit (which declared the > > Exception type) the RTL can't convert the triggered runtime erro

Re: [fpc-devel] Problems building on i386-win32

Am 25.11.2020 um 00:37 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, This might be my own configuration, but can people check that i386-win32 works properly? I tried to build it to test one of my new optimisations, but got a failure when building the trunk (without my optimisations).

Re: [fpc-devel] Commits without log message

Am 26.11.2020 um 21:48 schrieb avx512 via fpc-devel: Hi, sorry, there were small changes in my private branch. Editing log messages is enabled for the FPC repository. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Problems building on i386-win32

Am 26.11.2020 um 21:48 schrieb J. Gareth Moreton via fpc-devel: I figured it was something like that.  I'm not sure which installer put it there, or if moving it to the System32 directory will cause something to catastrophically fail! Given that it seems to just silently ignore the issue of

Re: [fpc-devel] Problems building on i386-win32

J. Gareth Moreton via fpc-devel schrieb am Mi., 25. Nov. 2020, 09:51: > Aah, typical! C:\Windows\System32 is supposed to be for 32-bit DLLs, > while C:\Windows\System is 64-bit. Question is, what can I do to > resolve it? I'm not even sure what Common.dll is for. > Wrong. System32 -> Host

Re: [fpc-devel] Different handling of try..except depending on OS?

Am 10.12.2020 um 20:54 schrieb Bart via fpc-devel: No fpc in your linux vm ? I'm shocked... ;-) Well, no trunk ;-) On Windows I know how to easily switch between using compilers. 3.2.0 is in path and I have some batch files to change that for 3.0.4 and trunk respectively (only in the current

Re: [fpc-devel] Local classes and interfaces

Blaise--- via fpc-devel schrieb am Sa., 19. Dez. 2020, 12:47: > Behind the scene, the Closures implementation declares classes and > interfaces. And, because I strongly believe it to be conceptually the right > way, such entities are declared in the innermost routine scope. For example, >

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

Michael Van Canneyt via fpc-devel schrieb am Mi., 16. Dez. 2020, 12:47: > We can of course consider changing the current behaviour in the future, as > far as I > know there is no urgency in this ATM. There are other, more urgent tasks... > I agree. Please concentrate on anonymous functions and

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

Am 15.12.2020 um 20:00 schrieb bla...@blaise.ru: Consider this test case: ---8<--- {$mode ObjFPC} // EXPECTED: 'Error: Identifier not found "result"' // ACTUAL BUG #1: gets compiled operator - (const L, R: Char) returned: Char; begin result := 'Z' end; // EXPECTED: gets compiled //

Re: [fpc-devel] Generic instantiations as result types of procedural types

Am 16.12.2020 um 17:09 schrieb Blaise--- via fpc-devel: The patch http://hg.blaise.ru/public/fpc/rev/544a934d262e (attached) fixes the following: ---8<--- {$Mode Delphi} type G = class var X: T; // EXPECTED: gets compiled // ACTUAL: 'Error: Generics without specialization

Re: [fpc-devel] Method pointers to RECORD methods

Am 16.12.2020 um 15:01 schrieb Blaise--- via fpc-devel: The patch http://hg.blaise.ru/public/fpc/rev/0a8aff8d8273 (attached) fixes the following: ---8<--- {$Mode Delphi} type R = record var X: Integer; function Foo: Integer; end; function R.Foo: Integer; begin result := X

Re: [fpc-devel] Local classes and interfaces

Am 21.12.2020 um 16:22 schrieb Blaise--- via fpc-devel: On 19.12.2020 16:51, Sven Barth wrote: Considering that it's only intended for internal use, yes I'm aboard with that. Here is the first change: http://hg.blaise.ru/public/fpc/rev/7c78bfdaed9a (attached). Strictly speaking, some local

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

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 >

Re: [fpc-devel] AArch64 -> ARM cross compilation

Am 14.11.2020 um 15:12 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I need a little bit of assistance so I can stamp out these bugs for you. As silly as this sounds, I've mislaid my Arm-32 SD card so I have to develop on AArch64 exclusively on the Raspberry Pi. As a result I only

Re: [fpc-devel] Fpc does not allow Chr() in type definition. Bug?

Benjamin Rosseaux via fpc-devel schrieb am Fr., 20. Nov. 2020, 12:40: > With the latest systemh.inc regarding this, the building of FPC SVN > Trunk for the x86_64-win64 target with FPC 3.2.x as bootstrap compiler is > failing: > > E:/FPC/bootstrap/ppcx64.exe -XX -Cr- -CR- -Ct- -Co- -CO- -C3-

Re: [fpc-devel] Fpc does not allow Chr() in type definition. Bug?

Florian Klämpfl via fpc-devel schrieb am So., 8. Nov. 2020, 22:18: > Am 07.11.2020 um 23:00 schrieb Bart via fpc-devel: > > Hi, > > > > Type > >SubRange = Chr(1)..Chr(2); > > begin > > end. > > > > This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't. > > > > Free Pascal Compiler version

Re: [fpc-devel] Compiler message colour scheme

Michael Van Canneyt via fpc-devel schrieb am So., 22. Nov. 2020, 17:03: > > > On Sun, 22 Nov 2020, Jonas Maebe via fpc-devel wrote: > > > On 22/11/2020 16:03, Ryan Joseph via fpc-devel wrote: > >> What version of the trunk is this in and what's the flag to enable it? > My trunk is maybe 30 days

Re: [fpc-devel] Compiler message colour scheme

Am 22.11.2020 um 16:44 schrieb Kirinn via fpc-devel: The feature request was here: https://bugs.freepascal.org/view.php?id=37331 It's magenta because GCC etc use magenta for warnings too. Actually, for those of us with white terminal backgrounds, yellow text would be hard to see, while

Re: [fpc-devel] Compiler message colour scheme

Am 22.11.2020 um 15:59 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, This might be me being a little bit picky, but I noticed the new colouring scheme for words like "Warning" and "Error" in the output logs.  Is there any particular reason why "Warning" is in magenta?  Normally the

Re: [fpc-devel] Compiler message colour scheme

Am 22.11.2020 um 17:40 schrieb J. Gareth Moreton via fpc-devel: Most modern Macs are Unix-based, so the escape sequences should work, right? Granted, I think we need someone with a Mac or a Mac virtual machine to test it for sure. Considering that Jonas doesn't support the textmode IDE on

Re: [fpc-devel] Compiler message colour scheme

Am 22.11.2020 um 17:19 schrieb J. Gareth Moreton via fpc-devel: I believe that to enable colour on a Windows console, you need to use an API function, which can get a bit clumsy because there isn't an equivalent to \e[0m to reset to default, so you have to retrieve the current console colour

Re: [fpc-devel] Compiler message colour scheme

Am 23.11.2020 um 01:59 schrieb J. Gareth Moreton via fpc-devel: I'm glad there's still interest in pure functions.  It may be a while though, and I'm being tempted with a bounty and Patreon pledges to implement "static single assignment" into the Free Pascal Compiler.  That will take some

Re: [fpc-devel] Error: Global Generic template references static symtable

Bart via fpc-devel schrieb am Fr., 8. Jan. 2021, 20:07: > It seems I cannot use a stand-alone function that is declared in the > implementation of the unit? > Correct. Why is that? > Generics are a stream of tokens that is reparsed when specialized. Functions declared in the implementation

Re: [fpc-devel] Error: Global Generic template references static symtable

Am 09.01.2021 um 16:21 schrieb Bart via fpc-devel: The *why* is not important for users. Those that are interested can ask, just like you did. Then let me rephrase it. Error messages of the compiler normally point you in the right direction like: qtest.lpr(367,3) Fatal: Syntax error, ";"

Re: [fpc-devel] Error: Global Generic template references static symtable

Bart via fpc-devel schrieb am Sa., 9. Jan. 2021, 05:17: > On Fri, Jan 8, 2021 at 9:00 PM Sven Barth via fpc-devel > wrote: > > >> It seems I cannot use a stand-alone function that is declared in the > >> implementation of the unit? > > > Generics are a st

Re: [fpc-devel] access violaion

Am 13.01.2021 um 21:15 schrieb John Lee via fpc-devel: when using viewcvs http://svn.freepascal.org/cgi-bin/viewvc.cgi/?sortby=date#dirlist gives access violation/file not found - worked yesterday! ! Please don't

Re: [fpc-devel] Patch for uf2 support in freePascal

Michael Ring via fpc-devel schrieb am Fr., 22. Jan. 2021, 23:38: > Hi Florian, im Anhang der Path für den UF2 Support in freepascal, ich > hoffe er passt so für Dich... > I take it this wasn't intended for the list? ;) Regards, Sven ___ fpc-devel

Re: [fpc-devel] Creating uf2 files for arm-embedded and Raspberry Pi Pico

Alfred via fpc-devel schrieb am Mo., 25. Jan. 2021, 11:25: > As there is (hopefully) more embedded and freertos coming to FPC trunk > soon, I would like to ask for a feature. > > Would it be possible to emit the -Wp definition ? > And perhaps also the -Cp definition ? > > Using embedded-freertos

Re: [fpc-devel] Proposal for implementing named address space support

Christo Crause via fpc-devel schrieb am Di., 19. Jan. 2021, 05:37: > > > On Sun, Jan 17, 2021 at 3:51 PM Florian Klämpfl via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Am 08.01.21 um 22:00 schrieb Christo Crause via fpc-devel: >> > On Sun, Oct 4, 2020 at 1:49 PM Christo Crause > >

Re: [fpc-devel] ROL/ROR with Carry

Am 11.01.2021 um 19:53 schrieb Karoly Balogh via fpc-devel: Hi, On Mon, 11 Jan 2021, Sven Barth via fpc-devel wrote: So the idea is to add support for ROL/ROR with Carry support as the current Rol*/Ror* functions don't support that. Florian then said that he's open to suggestions under some

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

Blaise--- via fpc-devel schrieb am Mi., 16. Dez. 2020, 10:14: > > The modeswitch Result enables the use of Result as an alias for *any* > routine … > > Incorrect. The identifier Result does not alias the routine, it aliases > the routine's return value. > For non operators the routine's name

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

Am 03.02.2021 um 20:25 schrieb Florian Klämpfl via fpc-devel: Am 02.02.21 um 22:06 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I've found a potential optimisation for conditions of the form "(x <> 0) and (y <> 0)", which are very common because this is semantically equivalent to

Re: [fpc-devel] FPC & Lazarus moving to gitlab

Ryan Joseph via fpc-devel schrieb am Di., 22. Juni 2021, 23:49: > > > > On Jun 22, 2021, at 10:05 AM, Michael Van Canneyt via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The date for the final conversion has been established as the weekend of > > 17/18 july. People that wish to

Re: [fpc-devel] FPC & Lazarus moving to gitlab

Am 23.06.2021 um 00:09 schrieb Ryan Joseph via fpc-devel: On Jun 22, 2021, at 4:02 PM, Sven Barth wrote: The plan has *never* been GitHub. The original plan was self hosted with a *mirror* on GitHub. Now we'll instead use GitLab as main repository with a mirror on GitHub. How does the

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 09.05.2021 um 17:14 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 3:40 AM, Sven Barth wrote: === code begin === {$mode objfpc} type TTest = class protected procedure DoSomething; end; TTestSub = class refcounted(TTest) public procedure Test; end;

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 3:40 AM, Sven Barth wrote: It seems that you don't work much with classes then. If one disallows the assignment of a reference counted class to a non-reference counted one then you can't use e.g.

Re: [fpc-devel] Implicit function specialization precedence

Am 12.05.2021 um 17:50 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 1:30 AM, Sven Barth wrote: Essentially it will boil down to sym.ChangeOwner(pd.parast) However you need to keep the Owner (which is different from what you change with ChangeOwner) different as otherwise

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 10.05.2021 um 23:18 schrieb Ryan Joseph via fpc-devel: On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel wrote: Why should they? You pass the reference to a non-reference counted parameter/field/variable, the reference count is increased and then what? It sits

Re: [fpc-devel] Defer keyword

Am 07.05.2021 um 00:32 schrieb Ryan Joseph via fpc-devel: On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel wrote: There is a performance penalty when using them, which one reason why the compiler sources don't use them. There's probably other reasons too. There might be some

Re: [fpc-devel] Defer keyword

Am 07.05.2021 um 00:17 schrieb Ryan Joseph via fpc-devel: On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel wrote: Other than that, you're right and what Ryan is trying to do is definitely the intended purpose of try ... finally. Is there any runtime code involved with try..finally

Re: [fpc-devel] Implicit function specialization precedence

Am 22.04.2021 um 17:52 schrieb Ryan Joseph via fpc-devel: On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote: Got this all integrated and put up the changes to https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another final review. :) The next thing to do now is to handle a

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 08.05.2021 um 18:23 schrieb Ryan Joseph via fpc-devel: On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel wrote: It has the exact same problems that my branch had (especially the interaction of reference counted instances with non-reference counted ones). Using a variable/parameter

Re: [fpc-devel] Implicit function specialization precedence

Am 06.05.2021 um 17:33 schrieb Ryan Joseph via fpc-devel: I found something sneaky I'd like to confirm before I decide what to do about it. 1) "T" in TAnyClass is specialized as Integer from the first parameter with TSomeClass (which is TAnyClass). 2) "U" is getting specialized as String by

Re: [fpc-devel] Defer keyword

Michael Van Canneyt via fpc-devel schrieb am Fr., 7. Mai 2021, 08:14: > > > On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: > > > > > In my opinion the better solution is to continue the road that Maciej > > started and to implement that "default field&

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 08.05.2021 um 19:38 schrieb Ryan Joseph via fpc-devel: On May 8, 2021, at 11:18 AM, Sven Barth wrote: It's not about reference counted classes vs. managed records, but about whether it's *per type* or *per variable*, the implementation details are completely irrelevant for now. So the

Re: [fpc-devel] Implicit function specialization precedence

Ryan Joseph via fpc-devel schrieb am Sa., 8. Mai 2021, 22:33: > > > > On May 8, 2021, at 12:04 PM, Sven Barth > wrote: > > > > You need to use ChangeOwner as well, but as I wrote you need to pay > attention for which created symbol you do it at what time. > > Ok, maybe this is what I got wrong

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Ryan Joseph via fpc-devel schrieb am Fr., 7. Mai 2021, 05:58: > > > > On May 6, 2021, at 7:14 PM, Ryan Joseph wrote: > > > > This can be detected at compile and at least give a warning. "a" is a > member of TR and the element type of "a" is TR, then we're assigning TR to > said array. It's that

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

Am 18.05.2021 um 15:24 schrieb Martin Frb via fpc-devel: I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   (MethodKind : TMethodKind;    ParamCount : Byte;    ParamList : array[0..1023] of Char {in

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

Am 18.05.2021 um 15:50 schrieb Martin Frb via fpc-devel: On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

Am 18.05.2021 um 17:33 schrieb Martin Frb via fpc-devel: On 18/05/2021 15:50, Martin Frb via fpc-devel wrote: On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

Am 19.05.2021 um 22:42 schrieb Martin Frb: On 19/05/2021 22:10, Sven Barth wrote: Am 18.05.2021 um 15:24 schrieb Martin Frb via fpc-devel: I was looking at TypeInfo (based on 3.2.2rc) . fpc_3.2.2\source\tests\webtbs\tw12038.pp    line 194    procedure DisplayDetails(Informations :

Re: [fpc-devel] Implicit function specialization precedence

Am 15.05.2021 um 18:27 schrieb Ryan Joseph via fpc-devel: On May 13, 2021, at 2:38 PM, Sven Barth wrote: Ah, you need to use ChangeOwnerAndName then and simply pass in the same name you used for the constructor (cause otherwise it tries to use the name that is currently stored in the

Re: [fpc-devel] Implicit function specialization precedence

Am 15.05.2021 um 20:08 schrieb Ryan Joseph via fpc-devel: On May 15, 2021, at 10:49 AM, Ryan Joseph wrote: Also it looks like ChangeOwnerAndName isn't making the compiler happy. Sorry for the noise, I figured out it was because the name had spaces. How should I make the name then? I'm

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

Am 07.05.2021 um 23:16 schrieb Ryan Joseph via fpc-devel: On May 7, 2021, at 2:52 PM, Sven Barth wrote: As said the main problem of reference counting on object instances, especially if enabled by default like the Delphi NextGen compiler did, will lead to problems in *existing* code and

Re: [fpc-devel] Defer keyword

Am 07.05.2021 um 17:40 schrieb Benito van der Zander via fpc-devel: The introduction of generics and their abundant use in Delphi has noticably slowed down the compiler and increased binary sizes. To my dismay, compile times of 20 seconds up to 2 minutes have become not uncommon in Delphi.

Re: [fpc-devel] Defer keyword

Am 07.05.2021 um 17:57 schrieb Ryan Joseph via fpc-devel: On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel wrote: I cannot speak for others, but I think 90% of potential use cases for ref counting would be covered like this in my code: objects that only live inside a procedure. I

Re: [fpc-devel] Defer keyword

J. Gareth Moreton via fpc-devel schrieb am Do., 6. Mai 2021, 20:03: > The rule with try...finally is that, outside of something completely > catastrophic that destroys the program flow, is that once you enter the > try part, the finally part is guaranteed to be executed no matter how > you leave

Re: [fpc-devel] mantis 0038496 custom variants and documentation

Am 30.05.2021 um 00:53 schrieb Marco van de Voort via fpc-devel: Before the 3.2.2 release I looked into mantis 0038496 and now I come back to it. I noticed that custom variants are completely undocumented, is this know (IOW should I file a bug?). What I wanted to look up are the rules for

Re: [fpc-devel] mantis 0038496 custom variants and documentation

Am 30.05.2021 um 11:39 schrieb Don Alfredo via fpc-devel: https://synopse.info/forum/viewtopic.php?id=5894 I'm already working on a fix for this, cause I had seen that thread a few days ago already. It would have been nice however if you had

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

J. Gareth Moreton via fpc-devel schrieb am Do., 1. Juli 2021, 01:29: > Ah curses. I fear it was something I did. I don't like the idea of > stepping through each revision until we find one that works. > That's where bisecting comes into play: find a revision where it is working (or not

Re: [fpc-devel] TDef flags

Am 03.07.2021 um 15:01 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I'm trying to fix i38827, and am trying a few things.  One thing I've noticed is that some specializations have both the df_generic and df_specialization flags set, and the def missing from the debug information

Re: [fpc-devel] TDef flags

Am 04.07.2021 um 12:59 schrieb J. Gareth Moreton: Okay, okay. Not too harsh, please. Better to stop the intention of modifying defs before you can get a taste for them. :P I feel I don't yet know enough about defs and generics to properly fix this bug, only that the defs used aren't

Re: [fpc-devel] Nested function closures

Am 27.04.2021 um 17:44 schrieb Ryan Joseph via fpc-devel: Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. if the compiler devs will allow me as soon as this is finished I want to allow the existing nested functions functionality to work with anonymous

Re: [fpc-devel] Nested function closures

Am 27.04.2021 um 17:58 schrieb Michael Van Canneyt via fpc-devel: On Tue, 27 Apr 2021, Ryan Joseph via fpc-devel wrote: Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. if the compiler devs will allow me as soon as this is finished I want to allow the

Re: [fpc-devel] Nested function closures

Am 27.04.2021 um 21:19 schrieb Ryan Joseph via fpc-devel: On Apr 27, 2021, at 12:10 PM, Sven Barth via fpc-devel wrote: So as Sven wrote, you would be duplicating effort, needlessly, since it has to work always... If the compiler can decide that the heap interface is not needed

Re: [fpc-devel] Type helper bug

Zeljko Avramovic via fpc-devel schrieb am Mi., 5. Mai 2021, 12:42: > In example bellow, both record field ID.PGN and type helper for that > record field ID.PGN.PS point to the same memory location in a bitpacked > record not aligned to a byte. ID.PGN can be modified correctly. ID.PGN.PS > can

Re: [fpc-devel] Implicit function specialization precedence

Am 06.04.2021 um 17:45 schrieb Ryan Joseph via fpc-devel: Finally some movement is happening on implicit function specialization and I'm almost finished now except some questions about precedence have been raised again. Initially I thought we decided on non-generic functions taking precedence

Re: [fpc-devel] Implicit function specialization precedence

Am 06.04.2021 um 22:47 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: In this specific case the two functions also are *not* ambigous, because for the non-generic Test the parameter requires an implicit conversion, but the implicit specialization does

Re: [fpc-devel] Implicit function specialization precedence

Am 06.04.2021 um 23:11 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: In the example you posted below, I agree with you, but that is not what I said. Look at my example again: Also could you please verify that $H+ isn't causing problems? The string

Re: [fpc-devel] function GetCurrentThreadId vs variable ThreadID

Am 28.03.2021 um 21:46 schrieb Alexander Grotewohl via fpc-devel: looks like threadid is assigned to getcurrentthreadid in an initthread() function in thread.inc. but: getcurrentthreadid looks to be mapped to a changeable thread manager which is why that might seem weird in the docs..

Re: [fpc-devel] Annoying error when building compiler on i386-win32

Am 05.04.2021 um 20:33 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I have a slightly annoying error when building the compiler for i386-win32.  I mentioned it to Sven a while ago, and the cause is due to the fact that my copy of common.dll is 64-bit, not 32-bit (as Sven confirmed

Re: [fpc-devel] Implicit function specialization precedence

Am 07.04.2021 um 18:16 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 11:34 PM, Sven Barth wrote: In the second case the compiler will have the non-generic Test(String) due to the implicit operator as well as Test(LongInt) due to the implicit specialization. Here it will pick the

Re: [fpc-devel] Implicit function specialization precedence

Am 08.04.2021 um 19:28 schrieb Ryan Joseph via fpc-devel: On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote: Ok, so with $H+ constant strings will be specialized as AnsiStrings. And there is another unicode string mode I should do a similar thing with? Also if you happen to know where I can

Re: [fpc-devel] Implicit function specialization precedence

Am 07.04.2021 um 23:21 schrieb Ryan Joseph via fpc-devel: With the requested changes I believe some precedence rules have changed. These both should be "Can't determine which overloaded function to call" errors or the non-generic should take precedence because the functions are ambiguous (by

Re: [fpc-devel] Implicit function specialization precedence

Am 09.04.2021 um 04:20 schrieb Ryan Joseph via fpc-devel: On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: 1. you should not blindly assume that the def is a stringdef if it's not an arraydef; at least use an internalerror to protect against problems here 2. if it's really a stringdef and the

Re: [fpc-devel] Implicit function specialization precedence

Am 14.04.2021 um 23:49 schrieb Ryan Joseph via fpc-devel: On Apr 14, 2021, at 2:33 PM, Sven Barth wrote: Had a bit of time to look at this. You can try the attached patch. You can then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a mixed array. It works but it

Re: [fpc-devel] Implicit function specialization precedence

Am 09.04.2021 um 23:52 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 3:08 PM, Sven Barth wrote: Possibly, yes... You could provide the various utility functions in a separate patch. Well I'm going to use them for this patch so they would all be batched together. Any idea about the

Re: [fpc-devel] Implicit function specialization precedence

Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel wrote: You mean what you did for is_array_literal? A pure array constructor can be found with is_array_constructor, though it might be better to use is_open_array, cause someone

Re: [fpc-devel] Implicit function specialization precedence

Am 10.04.2021 um 10:38 schrieb Sven Barth: Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel wrote: You mean what you did for is_array_literal? A pure array constructor can be found with is_array_constructor, though it might

Re: [fpc-devel] Implicit function specialization precedence

Ryan Joseph via fpc-devel schrieb am Fr., 16. Apr. 2021, 00:38: > > > > On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote: > > > > It works but it thinks this array is array of const also so it's too > strict I believe. > > > > ['aaa', 'bbb']; > > About this, shouldn't we just be doing this? Any

Re: [fpc-devel] Implicit function specialization precedence

Am 11.04.2021 um 23:38 schrieb Ryan Joseph via fpc-devel: On Apr 11, 2021, at 3:33 PM, Sven Barth wrote: Looking at it, it could be that there is a bug in tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll have to look at that first, but I don't know when I'll

Re: [fpc-devel] Generic class comparison operators

Ryan Joseph via fpc-devel schrieb am So., 18. Apr. 2021, 02:18: > Since I'm working on generics right now can we finally, at the very least, > allow class operators for comparison operators? This is literally the only > way for a generic class to override the = operator (along with some others)

<    1   2   3   4   5   6   7   8   >