Generics + const + sizeof = Invalid Expression, (((sometimes)))

[Plutonium Zepellin]

Hi.

I've found a bug in fpc related to SizeOf in generic record const expressions (fpc version is stable; 3.2.2 - obtained by following the link from freepascal.org website a month or so ago).

Reported it here: https://gitlab.com/freepascal.org/fpc/source/-/issues/41419

Issue status is marked as "Confidential" - should I may be do something else in addition to that?

I've tried searching the issue list before posting, my case seems to be unique.

May be retest it using the development version of the compiler?

Thanks,
...

[bytebites]

Confidential? Are you kidding?

[Martin_fr]

I don't think it needs to be confidential.

Even if you found that while working under NDA or at work, the code sample does not seem to contain any real word info. But you can check that with whomever you believe to owe liability.

As for the report, the code works in 3.3.1. But it does not in my copy of 3.2.3 (about 2 month old). So it likely also isn't (yet?) fixed in the upcoming 3.2.4. (I have not tested the RC).

[PascalDragon]

Issue status is marked as "Confidential" - should I may be do something else in addition to that?

I've disabled the confidentiality. There isn't really anything in that report that would warrant that.

May be retest it using the development version of the compiler?

That is usually the best.

[Plutonium Zepellin]

Confidential? Are you kidding?

Well, apparently that's the default tag for the issues and I could not do anything about that, sadly.

Also, I've found Internal Error 2007-something-something while compiling code with generic (generics, again) pairs.

Although it's just compiler dying after (rightly) emitting the warning/error list.

That is usually the best.

Ok. I'll probably have to look for the way of switching between compilers if I'll want the dev version or run into something I won't be able to circumwent somehow.

Thanks,
...

[Thaddy]

Also, I've found Internal Error 2007-something-something while compiling code with generic (generics, again) pairs.

@Plutonium Zepellin

Can you specify "2007 something" as the full internal error so we can report it?
You should always report internal errors (with replicable code):
internal error numbers are inserted by the compiler developers so they can trace code paths that are not supposed to happen inside the compiler and therefor it is very important to report them so they can be fixed.
It is kind of a last resort to debug the compiler itself. They are also rare to surface.

It should look like this, but probably a bit different: 2007010210, so like 2007<xxxxxx>
(although I picked a real internal error example, so by chance it could be yours, it is traditionally a date in yyyymmdd notation + sequence number, I believe)

You did not report it in your bug report - fixed in trunk -, but here you refer to it.
You can grep the compiler sources to find where it happens. Also note that if it is related to your bug report about 3.2.2 it won't be fixed in 3.2.2, it is fixed in trunk and maybe back-ported to 3.2.4  but I can only tell if we know the exact internal error.

[Plutonium Zepellin]

@Thaddy

Can you specify "2007 something" as the full internal error so we can report it?

Ah, it was another generics-related error. I have the code sample saved, although I did not scoop the bug tracker for the lookalikes yet.

I can probably prepare another bug report, but it'll again be for the fpc stable (3.2.2) from the debian amd64 perspective.

Alternatively, I can compile development version of the compiler myself, but it'll take some time.


PS.

Also, I've found some possible vandalism in the "Pascal Programming Language" wikibook.

(Upside-down text & code, see the screenshot is in the attachments).

Where do I report THAT?

[Thaddy]

It is the same text as the last paragraph, just remove it if you have enough credits to edit the wiki.
I can do that for you - if it is in our own wiki, can't find it - if you want? I suspect an accident, maybe a joke,  and no malicious intend.

And I still see no full internal error?

[Plutonium Zepellin]

@Thaddy

No, it's fullscale vandalism - just checkout the print version here: https://en.wikibooks.org/wiki/Pascal_Programming/Print_Version


As for Internal Error 20XX - I need to get to my PC for that.

It'll happen, eventually 

As far as I can remember it now it happens when I try to overload assignment/multiplication operators inside generic pair record types.

Something like that:

Code: Pascal  [Select][+][-]

1. {$modeswitch advancedrecords}
2.  
3. type
4.  
5. generic TPair <TFirst, TSecond, TScalar> = record
6.   a: TFirst;
7.   b: TSecond;
8.  
9.   { := overload for: TScalar := TPair   (sum)  }
10.   { := overload for: TPair   := TScalar (fill) }
11.  
12.   { *  overload for: TPair   *  TPair   (returning) TPair   // element-wise product    }
13.   { *  overload for: TPair   *  TScalar (returning) TPair   // upscaling / downscaling }
14.  
15.   { Adding the overload below triggers internal error after emitting the warning & error logs }
16.   { Basically, compiler tells me what's wrong and then internal errorly dies                  }
17.  
18.   { *  overload for: TPair   *  TPair   (returning) TScalar // dot product }
19. end;
20.  
21. TScalar1 = double;
22. TPair2   = specialize TPair <TScalar1, TScalar1, TScalar1>;
23. TPair3   = specialize TPair <TPair2,   TScalar1, TScalar1>;
24. TPair5   = specialize TPair <TPair3,   TPair2,   TScalar1>;
25. TPair6   = specialize TPair <TPair3,   TPair3,   TScalar1>;
26.  
27. { ... }
28.  
29.  

That's as best as I can remember it for now.

Got to go; I'll post the full details when I'll get closer to the codebase on my PC.

Then again, it's probably already been fixed in the development version.


Thanks,
...

[Thaddy]

From what I can see, provided you use the TPair<T> from generics.collections, you won't get internal errors:

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode objfpc}{$endif}
2. uses
3.   generics.collections; // for TPair<T>
4.  
5. type
6.   TScalar1 = double;
7.   TPair2   = specialize TPair <TScalar1, TScalar1, TScalar1>;
8.   TPair3   = specialize TPair <TPair2,   TScalar1, TScalar1>;
9.   TPair5   = specialize TPair <TPair3,   TPair2,   TScalar1>;
10.   TPair6   = specialize TPair <TPair3,   TPair3,   TScalar1>;
11.  
12. begin
13.   writeln('TPair4 is missing..');
14. end.

[Plutonium Zepellin]

@Thaddy, I was not asking how to get this code working;

What I was asking was:

"Whether I should report this as an another bug in the compiler, because it generates an Internal Error during compilation"

and

"Whether I should retest this using the most recent (development/unstable) version of the compiler".

As far as my current internal judgement goes the first question is still standing, the second one is resolved somewhat.

That and the question where I should report wikisource book vandalism.


Thanks,
...

[PascalDragon]

Confidential? Are you kidding?

Well, apparently that's the default tag for the issues and I could not do anything about that, sadly.

It's not default.

What I was asking was:

"Whether I should report this as an another bug in the compiler, because it generates an Internal Error during compilation"

and

"Whether I should retest this using the most recent (development/unstable) version of the compiler".

If you're able to test with a development version:

- if you can verify the issue with the development version then you should report it
- if you can't verify the issue with the development version then you should not report it

If you're not able to test with a development version:

- just report it, someone else will probably test with a development version then

Always include the used compiler version, source and target CPU and OS and the used option together with a self contained example, please, so that we don't have to guess.

[Plutonium Zepellin]

@PascalDragon I was not able to find anything in the gitlab UI to remove the "Confidential" tag that was automatically added when I've created the issue.

Probably an access control thing or me being silly, or aliens.

As for testing using the dev version: https://packages.debian.org/search?suite=sid&searchon=names&keywords=fpc says that even in unstable fpc is still version 3.2.2.

That means that in the absence of fresh *.debs I'll probably have to compile it myself. Owie. It's doable, but I'll probably have to concoct a chroot + build environment for that, etc etc.

Also, in addition to the error mentioned in the Thread Starting Post I've already stubled upon 2 different "Internal Errors" and an "Illegal Expression" problem with default multi-dimensional array properties (and, yes, generics are involved in ALL of them) - all in stable, obviously.

They are probably not that critical (syntax sugar/syntax preference/exploratory programming mostly), although the last one is annoying.

So, I've elected to report them at my leasure, for now at least.

Then again, if you want to speed things up just send me a PM/leave a message here in the thread.


Thanks,
...

[PascalDragon]

@PascalDragon I was not able to find anything in the gitlab UI to remove the "Confidential" tag that was automatically added when I've created the issue.

Probably an access control thing or me being silly, or aliens.

I don't know if a normal user can remove the flag afterwards, but when you start a new issue it isn't the default.

As for testing using the dev version: https://packages.debian.org/search?suite=sid&searchon=names&keywords=fpc says that even in unstable fpc is still version 3.2.2.

That means that in the absence of fresh *.debs I'll probably have to compile it myself. Owie. It's doable, but I'll probably have to concoct a chroot + build environment for that, etc etc.

There are no debs for the development version. You need to build/install manually.

Also, in addition to the error mentioned in the Thread Starting Post I've already stubled upon 2 different "Internal Errors" and an "Illegal Expression" problem with default multi-dimensional array properties (and, yes, generics are involved in ALL of them) - all in stable, obviously.

They are probably not that critical (syntax sugar/syntax preference/exploratory programming mostly), although the last one is annoying.

Even if they are not critical for you, it would be good to know them nevertheless. As said, you can also report them for the release version and someone else will hopefully find the time to verify whether the bug still exists.

[Plutonium Zepellin]

I don't know if a normal user can remove the flag afterwards, but when you start a new issue it isn't the default

It is, or at least it was, in my case. As I said - probably the matter of access control or something like that.

There are no debs for the development version. You need to build/install manually

Well, I was mostly interested in build automation scripts; seems like they are also all for 3.2.2.

It's probably just a matter of updating a version number and url though, probably.

Even if they are not critical for you, it would be good to know them nevertheless. As said, you can also report them for the release version and someone else will hopefully find the time to verify whether the bug still exists

I think I may have to update to dev/trunk anyway, since it may have better support for generics.


Thanks,
...