I’m getting a system.argumentoutofrange exception from the current version of Oxygene. I never had this problem with the trial version, which I was using until an hour ago, but ran into it immediately with the downloaded release version. It happens when I simply add a new local variable within a method, and is repeatable.
I ran into this while trying to workaround a lambda var or out error that I also never saw with the trial version. It concerned accessing a method’s var variable, and I don’t see why that should have been OK in the trial version, but not this one.
There were a number of other surprising differences between this compile and with the trial version. How stable is this product, if I may ask?
------ Build started: Project: xxx, Configuration: Debug ------
error E0: Internal error: System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.Collections.Generic.List1.get_Item(Int32 index) at RemObjects.Oxygene.Code.MethodHeaderParameterInfo.GetParameter(Int32 No) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.VisitResolvedCallExpression(ResolvedCallExpression call) at RemObjects.Oxygene.Code.BaseVisitor.VisitExpression(Expression element) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.VisitExpression(Expression element) at RemObjects.Oxygene.Code.BaseVisitor.VisitAssignmentStatement(AssignmentStatement assignmentStatement) at RemObjects.Oxygene.Code.BaseVisitor.VisitStatement(Statement element) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.VisitStatement(Statement element) at RemObjects.Oxygene.Code.BaseVisitor.VisitBeginStatement(BeginStatement beginStatement) at RemObjects.Oxygene.Code.BaseVisitor.VisitStatement(Statement element) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.VisitStatement(Statement element) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.VisitMethodImplementation(IMutableMethodImplementation methodImplementation) at RemObjects.Oxygene.Code.Compiler.InlineVisitor.<DoInline>b__2(IMethodInfo arg) at RemObjects.Oxygene.Code.CombinedParsedType.ForAllMethods(Func2 action)
at RemObjects.Oxygene.Code.Compiler.InlineVisitor.b__0(IParsedType el)
at RemObjects.Oxygene.Code.Compiler.Compiler.ForAllInternalTypes(Action`1 aAt)
at RemObjects.Oxygene.Code.Compiler.InlineVisitor.DoInline(Compiler aTypes)
at RemObjects.Oxygene.Code.Compiler.Compiler.DoInline()
at RemObjects.Oxygene.Code.Compiler.Compiler.Compile()
Done building project “xxx.elements” – FAILED.
If it matters, the problem came up while I was editing a recursive method. At first, it used a var parameter. Oxygene 9 was OK with that, but 10 returned a lambda var out error at every reference in the method to the parameter. So I rewrote the method to return the value itself, no var parameter. That’s either when the problem arose, or was simply the last compile error I ran into after upgrading to 10, probably the latter. The above error never comes into play unless there are no other compile errors.
I also discovered that 10 no longer supports “if x in namedset.” That’s OK.
Compiles seem to find unused local variables, or variables assigned but not used, almost at random. That’s OK, but weird. 9 did that as well. New ones would popup unexpectedly.
9 (don’t know about 10) would sometimes insert var var var var var, if I forgot to include a var in a call.
Most amazingly, I made a reorganization error, the result being that a nested method was being called outside its scope and with too many parameters. 9 never caught that, 10 did. What was 9 doing with those statements?
Anyway, the first error is all I care about right now.
Can you send me the project that shows this? I don’t think I can solve it just from the exception. If you want to keep it private you can send it directly too (click my nickname). I’ll throw it away after I solve the issue.
FWIW, every build of the compiler we ship (and in fact, every of the dozens of full builds we create internally, every day) is compiled with itself. That means we use the compiler we’ve just built to rebuild itself, and to rebuild all the libraries, tool chains and IDEs. That usually finds any significant (and insignificant) problems really quickly and serves as a good dog-fooding.
On the flip side, it also means that any “obvious and glaring” bug in a build that made it out the door is usually not as quite obvious as it may seems, else our own millions of lines of code we built with that exact copy of the compile would have hit it, as well ;).
Also NB, the trial and full version of any given build are, literally, identical, and should not not have any differences at all. There will of course be differences (usually good, once in a while bad, if we indeed do introduce a regression) between one week’s build and the next, however.
Which build were you using as trial, and what build are you on now?
I apologize for the crack in the posting. Afterwards, I realize it was a public forum, not a private email, and had no business being there, but there was no way to edit it out. Let me change it now, and I will. This will sound dumb, but I had just read a blog on your site about the new build, and it had so many typos, it made me wonder if anything got double-checked there. So, I guess that’s another crack…
With that nonsense out of the way, the trial build was 9.3. All of the 10 builds exhibit the problem. I tried to backtrack to 9.3 to see if I had introduced a problem that was not, in fact, unique to 10, but apparently, it’s not possible to revert, because 9 couldn’t load the project after editing in 10.
Carlo asked about seeing the code, but it’s a massive simulation I brought over from Delphi. I’m going to rebuild it from the bottom up as a new project, and see where, if at all, the problem recurs. Is there anything specific I should be looking for, or is this just an internal fault that has no bearing on the code itself?
Well, that turned out to be easy to isolate: Oxygene 10 didn’t like two namespaces with nested methods that weren’t a problem for version 9. I simply moved the outer method declarations down to their corresponding begin…end block, and the error went away. Neither used local variables, so the nesting served no purpose. I have many other namespaces with nested methods that are not producing compiler errors. I don’t believe I can narrow this further.
unit issue79722_arraytest;
interface
uses System,System.Collections.Generic,System.Linq,System.IO;implementation
var R: array[1..10] of Byte;
begin
For X: Integer := 1 to 10 do
R[X] := X;
end.
and that works fine, results in (decompiled):
using System;
using System.Runtime.CompilerServices;
namespace issue79722_arraytest
{
[CompilerGenerated]
public static class __Global
{
internal static byte[] R;
public static int Main(string[] __args)
{
int num = 10;
int X = 1;
if (X <= num)
{
num++;
do
{
__Global.R[X - 1] = (byte)X;
X++;
}
while (X != num);
}
int Result;
return Result;
}
static __Global()
{
__Global.R = new byte[10];
}
}
}
I’m sorry about that. with post was that, specifically? normally all the posts get proofread, b ut sometimes something does slip thru the cracks…
Ah, ok. yes. the changeover from 9.3 to v10 is significant, so there’s a lot of changes, and also potential for some new bugs, as well.
Hm, that should be fine. what error did you get loading the project in 9.3? What IDE, Visual Studio or Fire? The project format has not really changed between the versions…
I’ll let Carlo handle the further discussion on the two compiler bugs…
I use array types, and am definitely running into this error. I’m going to start isolating the problem further now, but perhaps you’ll read this and beat me to it.
