E376: Member is obsolete: Types with embedded references are not supported in this version of your compiler

Hi

The latest preview release introduced a new compiler error E376 in our .NET 4.8 project.

This may be related to this change log line:

Delphi Compatibility: deprecated directive’s message was ignored

We use the ReadOnlySpan type when working with SkiaSharp :

var span := pixmap.GetPixelSpan;

The current stable release works fine. Is there an option to control the compiler’s E376 behavior? Changing the Delphi Compatibility setting doesn’t resolve the issue.

Regards

Artur

Hi Artur,

i’m not sure without full context. The deprecated keyword is supported in Delphi Compatibility Mode only; in regular Oxygene use the [Obsolete] attribute. We did make enforcement for some DCM-only keyworfds more strict in latest. But this still seems odd, especially if it shows in DCM too.

What’s the exact error?

Any chance we can see a (ideally small’ish) testcase that shows this?

/cc @david.millington

ConsoleApplication6.zip (30.6 KB)

In addition to this issue, there are other new issues introduced in the latest stable release related to the Delphi Compatibility flag.

E: Parenthesis are required to call method Size(), cannot assign method group to “Int64” [Program.pas (32)]
E: Type mismatch, cannot find operator to evaluate “Program” + “Int32” [Program.pas (33)]
E: Parameter 1 is “”, should be “Integer”, in call to Program.testInt(size: Integer) [Program.pas (34)]

Here is the modified Program.pas

namespace ConsoleApplication6;

uses System.Runtime.CompilerServices;

type
[Extension]
TProgramExtender = public static class
[Extension]
class function Size(const _part : Program) : Int64;
begin
  exit(1);
end;

end;

Program = public class
public

class method testInt( size : Integer );
begin
  
end;

class method Main(args: array of String): Int32;
begin
  var map := new SkiaSharp.SKPixmap();
  var fullSpan : ReadOnlySpan<Byte> := map.GetPixelSpan();
  var rowSpanAsBytes : ReadOnlySpan<Byte> := fullSpan.Slice(0, 1);
  
  var p := new Program();
  var s : Int64 := p.Size;
  var res := p + 1;
  testInt(p.Size);
end;

end;

end.

The compiler has a problem with an extension method and an implicit cast.

Also, the compiler reports an error when using MESSAGE:

{$MESSAGE WARN ‘Verify what to do on OSX/IOS’ }

Curious. It seems that error is “correct”, in that this type is simply marked as [Obsolete] (with the boolean true parameter telling the compiler to fail) in the .NET base library:

// System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Ref/10.0.0/ref/net10.0/System.Runtime.dll

[System.Runtime.CompilerServices.NullableContextAttribute(1)]
[System.Runtime.CompilerServices.NullableAttribute(0)]
[System.Runtime.CompilerServices.IsByRefLikeAttribute]
[ObsoleteAttribute("Types with embedded references are not supported in this version of your compiler.", true)]
[System.Runtime.CompilerServices.CompilerFeatureRequiredAttribute("RefStructs")]
[System.Runtime.CompilerServices.IsReadOnlyAttribute]
[System.Reflection.DefaultMemberAttribute("Item")]
[System.Runtime.InteropServices.Marshalling.NativeMarshallingAttribute(typeOf(System.Runtime.InteropServices.Marshalling.ReadOnlySpa

[quote="arturredzko, post:4, topic:33060"]
E: Parenthesis are required to call method Size(), cannot assign method group to “Int64” [Program.pas (32)]
[/quote]

nMarshaller<T,TUnmanagedElement>))]
System.ReadOnlySpan<T> = public sealed record

i’m not sure why exactly; we’ll have to do some research. But aside from what the message says, this is nothing specfic to the version of our (your :wink: compiler, that just is a jardcoded message that Microsoft put on the type…

I’m guessing VC# has some “compiler magic” specifc to this type and Microsoft wants to keep other compilers from using it as-is.

FWIW, this error does not seem to be new; i can set the project back as far as .NET Core 3 and it has the same attribute.

Thats a curuious one, as it only happens in DCM. Size does require a parameter, so i’d expect “no overload with 0 parameters” instead of this error.

Oddly if i move the extension method into he class, i get all three:

  var s : Int64 := p.Size; // E500 Parenthesis are required to call method Size(), cannot assign method group to "Int64"
                           // E318 No overloaded method "Size" with 0 parameters on type "Program"
                           // H15 Best matching overload is "method Size(_part: Program): Int64"

This one seems entirely expected; since there is no operator to concat Program and Integer, indeed?

And this one is probably a variation of the first. I’ll log a ticket for these two errors (as well as for Span).

Logged as bugs://E27614.

Logged as bugs://E27615.

As workaround, if you use Oxygene;s native extension class syntax it seems fine in DCM as well (but only if its remains marked as static. very odd).

  TProgramExtender = public extension class(Program)
    
    class function Size : Int64;
    begin
      exit(1);
    end;

  end;

Sorry, it should be p.Size + 1 :

It would be nice to compile this code as we do now, using version 12.0.0.3059.

Ah ok. if so, same issue as the line below, really.

Agreed, this is a bug that needs to be fixed. You say this was fine in 3059? If so, thats helpful info and helps us narrow this down. We did a lot of tweaks and improvements to DCM in the past few weeks, and one of them must have broken this.

:folded_hands:

Yes, I was devastated by the last preview and the over 200 errors in our solid, stable project. We always had issues with Java after your changes in the compiler, but never with .NET.

We have more errors compiling our projects (.NET and Java), but we will wait for these bugs to be fixed and test again.

Damn, i am sorry (and a bit shocked) to hear that. Please let me know ASAP so we cna have a look.

We always strive not have major regressions of course, but with DCM there might be some intended breaking changes coming, as we;re currentl;y doing. alot of work to bring DCM even closer to compiling Delphi code “as is”. Of cousre we need to find the right balance here to also not break exisiting Oxygene code that uses the DCM as it is/has been… :crossed_fingers:

If you don’t mind, i’ll loop you into the “firehose access” so you get acecss to or daily/whenever CI builds and can retest w/o waiting for the wekely updates, as as fix this…

Great, thanks.

bugs://E27614 was closed as fixed.

Artur,

this build firehose build should have the fixe for both of the issues you reported, as well as a whole bunch of additional fixes and impriovements for DCM. I’d appreciate if you could give it a go to see if it looks better for you – and let me kow any other regression issues you see with it, as you mentioned:

Great. Thanks. Here is the next test case project with errors :

(E500) Parenthesis are required to call method TrimStart(), cannot assign method group to “String”
(E513) Parenthesis are required to call method TrimEnd()
(E62) Type mismatch, cannot assign “Byte” to “^Void”
(E64) Type mismatch, cannot find operator to evaluate “” + “Char”
(E793) Untyped parameters are only supported on the Island platform

ClassLibrary.zip (8.1 KB)

Changing DCM to NO fixes string issues. Untyped parameters worked before.

For Java I have errors :

(E406) No overloaded method “Background” with these parameters on type “JLabel”, best matching overload is “setBackground(arg1: Color)”
(E486) Parameter 1 is “^RemObjects.Oxygene.System.Void”, should be “Object”, in call to tatukgis.rtl.disposeAndNil(_obj: Object)
(E486) Parameter 1 is “RemObjects.Oxygene.System.Integer”, should be “Color”, in call to TGIS_ValueValidator.setFontColor(_color: Color)
(E576) Cannot access member on expression without result type
(E62) Type mismatch, cannot assign “RemObjects.Elements.System.Byte” to “^RemObjects.Oxygene.System.Void”
(E62) Type mismatch, cannot assign “RemObjects.Oxygene.System.Integer” to “Color”
(E793) Untyped parameters are only supported on the Island platform

I noticed that here SuppressedWarnings matters.

consoleapplication7.zip (5.0 KB)

Logged as bugs://E27627. NRE building the Java project in non-DCM mode

              -> Phase Generating Output started.

E: Error while generating executable: Object reference not set to an instance of an object
← Phase Generating Output finished, took 0.045s.

This one is very weird, especially for Oxygene (the error itself is from C#, it’s is a “can-treat-as-fixed” error). The only time id expect something like this in Oxygene is when theres ambiguity about value vs call - say for a block or event, never for a real method.

This error is new and DCM-only.

(E62) Type mismatch, cannot assign “Byte” to “^Void”

this is the omnly error that also appears outside of DCM – and it seems somewhat valid. this should need a cast?

Update: this is related to untyped parameters. which are… dodgy, to say the least, esp on .NET. We need to review what the final outcome here is. Did this work before!? Not just compile, bit work?

(E793) Untyped parameters are only supported on the Island platform

IIRC this was a deliberate limitation; i recall discussing this with the team. Nut if so, it’s odd that this restruction woudl only apply to DCM. @david.millington i suggest we revert and allow this using the old behavior, on non-Island?

(E64) Type mismatch, cannot find operator to evaluate “” + “Char”

i see this as Class1.pas, line 90 — (E64) Type mismatch, cannot find operator to evaluate "<method group>" + "Char", s really this is the same issue as the E500 and E513 above, where it thinks it needs the (). Fixing that will also fix this.


FWIW, i had to add more wreferences ot the Java testcase; it all compiles file without DCM (after i cmment out strict, but NREs in a late clompile phase. Logged. SO all the reported issues are DCM-only:

(E406) No overloaded method “Background” with these parameters on type “JLabel”, best matching overload is “setBackground(arg1: Color)”

It seems we somehow lose “method to property mapping”, in DCM only. Background: Java doesn’t really have properties. any method pair of foo: x and setFoo(x) is treated as a property. Why this would have regressed in DCM-only; unsure.

(E486) Parameter 1 is “^RemObjects.Oxygene.System.Void”, should be “Object”, in call to tatukgis.rtl.disposeAndNil(_obj: Object)

i dont see this one here.

(E486) Parameter 1 is “RemObjects.Oxygene.System.Integer”, should be “Color”, in call to TGIS_ValueValidator.setFontColor(_color: Color)
(E62) Type mismatch, cannot assign “RemObjects.Oxygene.System.Integer” to “Color”

This is a case issue. Color is a class, it has a field RED of type Color and a property Red of type Integer. Sigh, that’ Java for you. But we need to check what changed that DCM–only now picks the wrong one.

Forcing the case with «» also doesn’t fix it:

      cnv.Color := java.awt.Color.«Red»;

Update: in non-DCM i ge this warning:

Program.pas, line 19 — (E464) Case for identifier “Red” does not match original case “RED”
Program.pas, line 23 — (E464) Case for identifier “Red” does not match original case “RED”

As it tries to use the “correct” (which is a relative term here, since neither really is more correct) one…

(E62) Type mismatch, cannot assign “RemObjects.Elements.System.Byte” to “^RemObjects.Oxygene.System.Void”

Same as above, imho this is “correct”.

(E793) Untyped parameters are only supported on the Island platform

Also see above.

@david.millington pls check into this with top prio. :folded_hands:

1 Like

To be clear: these appear all to be regressions related to our attemots to make DCM more compatible with actual Delphi code, and i deeply appologize for these.

That said, one or two if these might be here to stay (e.g. the Byte to ^Void seems like a valid and proper enforcement of something that maybe previouly was too lax); but i cant say yet until we reviewed those and what lead to them, in detail.

Today’s official build .3073 probably will not address any of these, but i hope to have a new firehose build that addresses some of them (but not all, thats a bit much for one day) for you, before the weekend. :crossed_fingers:

—marc