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

Thank you for the support.

The code that I managed to extract for the test case has always compiled and worked.

We have ~1000 tests that run the same codebase across different platforms.

(E500) It is weird. If I run the code in the default console app :

namespace ConsoleApplication8;

type
Program = class
public

procedure Val(
 const _str  : String  ;
 var _val  : Int64   ;
 var _code : Integer
) ;
begin
 var str : String  ;
 var i   : Integer ;
 _code := 0 ;
  for i := length( _str ) downto 1 do begin
    str := _str.Substring( 0, i ).TrimEnd ;
    str := _str.Substring( 0, i ).TrimEnd + '=' ;
  end ;
end ;

end;
end.

It compiles. There are lots of cases where a new template code (without a split to interface and implementation) compiles, but not in the “Delphi” template.

(E62) worked.

Without DCM, TrimEnd suggests a function without and with a parameter. In DCM mode, the code complete shows only one version with a parameter.

FreeObject( var _obj ) always worked. But e.g using FreeObject inside a Blazor project and a Task body crashes the app. I think we reported this some time ago.

Depending on Suppressed Warnings Color.red works or not. When I change it to RED, the editor replaces the selected to red. Without suppressing W I just get warnings about text case.

So the same code, depending on the project settings, compiles in a different way.

Anyway, I appreciate your work and improvements. I will test them in the next build.

Artur

Out of curiosity (i guess i could install an older compiler and check), how does your call site for

procedure read_scb( var _p : IntPtr; var _v; const _count : Integer; var _off : Integer ) ;
begin
...
    _v := Marshal.ReadByte( _p, _off ) ; // E62 Type mismatch, cannot assign "Byte" to "^Void"

look? are you passing a Byte variable, i assume – but what would hapen if you passed something else? At best that would cause a cast error, at worst it would eave the runtime in bad state and crash, on returning with Byte…

eg:

var x: String;
read_scb(0, x, 5, 5) ; // read puts a Byte into a String here. But the compiler doesnt know that from the signature..

Update: i did test on an older compler and indeed it fails with InvalidCastException. Fair enough, IMHO we can/should persist/restore that (in DCM mode).

The E500 and 513 errors 100% should not ever happen on Oxygene; that’s a bug. That said, for

        str := _str.Substring( 0, i ).TrimEnd ; // E500 Parenthesis are required to call method TrimEnd(), cannot assign method group to "String"
        str := _str.Substring( 0, i ).TrimEnd + '=' ; // E513 Parenthesis are required to call method TrimEnd()
                                                      // E64 Type mismatch, cannot find operator to evaluate "<method group>" + "Char"

i see that TrimEnd requires a parameter, as its defined as

  method TrimEnd(trimChars: array of Char): String;
  method TrimStart(trimChars: array of Char): String;

and if i pass a parameter, the erro goes away:

        str := _str.Substring( 0, i ).TrimEnd([' ']) ;
        str := _str.Substring( 0, i ).TrimEnd([' ']) + '=' ;

Oddly we havent reproduxed that standalone; in my tescases i get:

      foo; // E513 Parenthesis are required to call method foo()
           // E318 No overloaded method "foo" with 0 parameters on type "Program"
           // H15 Best matching overload is "class method foo(var aParam: Object): String"
      bar;
      var x: String := foo; // E500 Parenthesis are required to call method foo(), cannot assign method group to "String"
                            // E318 No overloaded method "foo" with 0 parameters on type "Program"
                            // H15 Best matching overload is "class method foo(var aParam: Object): String"

i.e. i always get the proper E318 alongside the bad E500/E513. Very strange. But the team is investigating what happened…

yeah thats sideeffect of us tightening the untyped parameters, see above. We’ll need to review.

Curious! That explains what i said above – and it might help us narrow this down. thanx!

:folded_hands:

And once again my apologies for this happening at all.

var _buffer : IntPtr ;
var _cnt    : Integer
var b        : Byte  ;

while True do begin
  read_scb( _buffer, b, 1, _cnt ) ;
....
1 Like

That’ll be ok, but note you get absoluteky zero compiler checking on wheher b/Byte is valid, here. If the methid was declaring var v: Byte, youd be safe – nothing lost.

But i agree we should keep this supported for Delphi Compatibility Mode (only).

I have a new internal build for you that should fix most (but not quite all) of the issues you reported: Login | Portal | RemObjects Software

1 Like

Thank you.

  1. Initial tests for .NET look good. The project compiles and runs. I will run big tests during the weekend. :+1:
  2. For Java, only an issue with java.awt.Color.red remains.
  3. I have one more issue in Blazor and .NET with using a Task with FreeObject inside.
function Layer.setUpAsync : Task<Integer> ;
begin
  Result := Task<Integer>.Run( ->
  begin
    // task body
    var res : Integer := 0 ;
    var obj : Object := new Object() ;

    FreeObject( obj ) ; // fails
    FreeObjectNotNil( obj ) ; // works

    await Task.Delay(1);
    Result := res;    
  end) ;
end;

To solve Blazor limitations with threads, we have functions like setUpAsync that, when awaited, start but do not resolve; they do not enter the task body. During debugging, it looks like the stack is broken and the async await flow (call and wait) is lost. The program continues without resolving the task.

The problem is using FreeObject( var _obj ) inside a task where there is an await. If we use the procedure FreeObjectNotNil( _obj : Object ), then it works fine. I don’t have a good test case.

It’s not a critical issue, as we found a workaround, but can you check if you can reproduce it and why it happens?

Thanks.

Awesome! I’ll truy to get you a new build b efore my end of day (.3075 probably will not get lost of this yet).

Yes, i believe that is still known-open, but ill check with @david.millington.

curious. are these from the legacy Delphi.RTL or did you impleent placeholders them yourself? I’m assuming thats a side efefct of the type-less parameters, still…

Thes do not come from Delphi.RTL, so id need to see how those are defined :folded_hands:

procedure FreeObject( var _obj ) ;
begin
  disposeAndNil( _obj ) ;
end ;

procedure FreeObjectNotNil( _obj : Object ) ;
begin
  FreeObject( _obj ) ;
end ;

i cannot reproduce with this test case;

namespace ConsoleApplication18;

type
  Program = class
  public

    class method Main(args: array of String): Int32;
    begin
      // add your own code here
      writeLn("The magic happens here.");
    end;

    method setUpAsync: Object;
    begin
      Result := Task<Integer>.Run(() -> begin
        // task body
        //var res : Integer := 0 ;
        var obj : Object := new Object() ;

        FreeObject( var obj ) ; // fails
        FreeObjectNotNil( obj ) ; // works

        //await Task.Delay(1);
        //Result := res;
      end) ;
            
    end;

    procedure FreeObject( var _obj ) ;
    begin
      disposeAndNil( _obj ) ;
    end ;
    
    procedure FreeObjectNotNil( _obj : Object ) ;
    begin
      FreeObject( var _obj ) ;
    end ;

  end;
  
  Task<T> = public class
  public
    
    class method Run(aBlock: block): Object;
    begin
      
    end;
  
  
  end;

end.

ConsoleApplication18 1.bugreport.zip (34.8 KB)

We have a new build for you: Login | Portal | RemObjects Software

1 Like

Thank you. Using a new build in Java projects, compilation ends with :

(E0) Internal error: System.NullReferenceException: Object reference not set to an instance of an object.
at h.VisitCastExpression(CastExpression a)
at h.VisitExpression(Expression a)
at h.a(Argument a)
at h.a(IParameters a)
at h.VisitResolvedCallExpression(ResolvedCallExpression a)
at h.VisitExpression(Expression a)
at h.VisitIfStatement(IfStatement a)
at h.VisitStatement(Statement a)
at h.VisitBeginStatement(BeginStatement a)
at h.VisitStatement(Statement a)
at RemObjects.Elements.Code.BaseVisitor.VisitScopeStatement(ScopeStatement element)
at h.VisitScopeStatement(ScopeStatement a)
at h.VisitStatement(Statement a)
at e.a(IMethodInfo a)
at RemObjects.Elements.Code.CombinedParsedType.ForAllMethods(Func`2 action)
at e.a(IParsedType a)
at e.f()
at e.GenerateExecutable()
at RemObjects.Elements.Code.Compiler.CompilerOuput.GenerateExecutable__$mapped(Compiler self)
at RemObjects.Elements.Code.Compiler.Compiler.Comp…

So previous errors are fixed (I think so), but I cannot run runtime tests.

1 Like

Hi Artur,

David here - marc has been present in the thread (thankyou) but I am the one implementing compatibility with Delphi – we have a project to build Spring4D, since it’s the most complex code Delphi we know of – and thus am the person who is responsible for these breakages. I’m glad the new build solves the ones so far, but I apologise for them in the first place as well as that something still exists.

I’m having trouble reproducing that crash, with a variety of tests and new apps. Would you be able to attach a repro of any sort, please? (If it contains confidential code, you could email to support@rembobjects.com to avoid it being on the forum.

Many thanks,

David

I will try to cut the project to a minimum to reproduce the issue.

1 Like

I sent an email to support with subject: “E376: Member is obsolete Java test case.” reference number 33273.

Please treat it as confidential code and delete it after testing.

Thankyou. I replied to that there, but absolutely, we will treat it appropriately and delete.

I repro-ed, and hope we have a fix. We have a build here: Login | Portal | RemObjects Software Would you be able to try it please?

1 Like

Great job. Java works again :slight_smile:

I tested only partially the project, but it seems to work. With the next public release, I will try to install this version on production to run all heavy tests. I appreciate your work. Thank you.

Artur

1 Like

Thankyou very much, I am really glad to hear it! Thankyou too for your patience here, as well as your help diagnosing and reproducing.

Please let us know of any other issues – I hope there are none, but I’m aware that when modifying the compiler there is risk around edge cases, and many of the changes we’ve been making are around syntax that is very edge case. Let’s touch wood that there are no more.

Just to note, today’s official build won’t have these fixes. This build was from a branch and needs to be merged, go through other tests etc.

1 Like

Please let me know which build I should take.