1. programs aren't compiling with "undefined named parameter:" they previously compiled. I've attached an LSX file compiled with 6.5.1707.1 / 6.5(953) hopefully that helps. 2. When compiling multiple programs I what's in the attached image and it aborts the program after 36 attempted compilations
Last edited by Stephen Funkhouser; 08 Apr 2212:59 PM.
I'm having trouble with the gpg decrypt (which I emailed you about). But regarding the first error, almost certainly it's due to this...
Quote
============================================================================ A-Shell Release Notes Version 6.5.1712.4 (20 March 2022) ============================================================================ 2. Compiler bug fix (edit 975) - named parameter references to arrays (byref) were incorrectly accepting scalar parameter name syntax. For example, for a function defined as follows ...
function fn'foo(aaa() as ST_ARRAY)
the compiler was accepting the following call ...
call fn'foo(aaa=bbb())
whereas since the formal parameter is an array, it should have required array syntax for the name reference, e.g. ...
call fn'foo(aaa()=bbb())
Somewhat worse, an attempt to use the correct syntax (as shown above) would have resulted in a mysterious compilation error -- unmapped variable for aaa().
Worse still, if the local array had the same name as the formal array parameter, e.g. ...
call fn'foo(aaa()=aaa())
... it accepted the syntax, but compiled the call incorrectly, mistaking the format named parameter aaa() for the locally defined aaa(), which almost certainly would have caused a crash at runtime.
The good news is none of these problems were likely to affect production systems. But the bad news is that you may now get a compiler error when compiling code using the incorrect fn'foo(aaa=bbb()) syntax, even though it previously compiled ok. Fortunately the fix is simple, and hopefully obvious.
It's unfortunate that the fix can't be backward compatible, but I'm not sure it's possible here.
The second problem I don't have any clues about yet. Are you compiling multiple programs within a CMD file within a single A-Shell session? Or are these calls to the standalone compiler. In the former case, it sounds like some resource being used up. But in the latter case that wouldn't be applicable and suggests something even more sinister.
Out of curiosity, what exactly did you fix? I have found (and am resolving) instances of the code not compiling because of 6.5.1712.4 what other issue was there?
The compiler fix in 978 was to deal with a small glitch in the logic that matches up named parameters specified in the call with the equivalent named parameter in the definition. It wasn't handling the case of a parameter like $ary()=.NULL as ordmap(varstr;varstr). It was working fine for scalar parameters and for arrays without initializers.
I'm not quite sure what I'm looking at in the image of the errors. It looks like a SEGV or core-dump type message, but you normally can only that once before your session is hosed. But the XCALL interface to the compiler runs within the caller's session, so that doesn't quite make sense. Is there anything useful in the ashlog? Does it always occur after the same number of compiles? Or after a particular program? Does increasing the memory size have any effect on it?
I think the only option is to increase the memory of the job, either in the MIAME.INI or by executing a MEMORY command at the dot prompt. Normally you would get an out-of-memory error if that were the issue, but it may be an edge case. Or it may be that it eventually dies no matter what (because it is failing to release something) but takes longer depending on how much you start with.
Doesn't appear to be related to memory then. Is it the same program being compiled 33 times, or 33 different programs? Is it always the same program that fails? Anything show up in the ashlog?
I guess we can attribute the unceremonious abort after 33 error-filled compiles to the "programmer sympathy" module that protects you from being overwhelmed by too many errors at once.
Seeing some random syntax errors when not using named parameters. You can see the compiler syntax error below. There are other calls not using named parameters to the same function that compile.
Code
ACCOUNTING.BSI[160,4]:295: ?Syntax error - exitcode = fn'accounting_gen'je_add(2)
! function signature
FUNCTION fn'accounting_gen'je_add(mode as b1,gen'je'rec as GEN'JE'RECORD_STRUCT) as f6
Also, the following is giving me a syntax error but other lines formatted the exact same way compile.
Code
f$ += Fn'Sprintf$("(i.special_order_item!='Y' AND i.website_flags & %d!=%d)", INV1_WEBSITE_EXCLUDE'STOCK, INV1_WEBSITE_EXCLUDE'STOCK)
All of these programs compiled successfully prior to 6.5.1712.4.
Once we get past fixing the syntax issues I can revert my code to see if the abort is still reproducible.
Last edited by Stephen Funkhouser; 11 Apr 2206:57 PM.
It does seem that there may be a floating gremlin or two causing spurious syntax errors, as if some variable wasn't getting properly initialized. It's really hard to track such problems down though without a reproducible case. (As you probably already realize, neither of the above generate errors in a simple test.) If you can send me an LSX that fails, it would definitely help.
I'm getting errors of the original type (i.e. missing parens in a named parameter), e.g.
Code
DIRECTORY'BSI:10664: ?Undefined named parameter: - .fn = fn'file_append(outfile$=outfile$%c aryct=1%c ary=ary()%c clear'outfile=clear'outfile%c formfeed=formfeed) <<ary>>
DIRECTORY'BSI:11157: ?Undefined named parameter: - CALL fn'file_conf_path_find_helper_set'default'paths(paths$=final'paths$()) <<paths$>>
DIRECTORY'BSI:11161: ?Undefined named parameter: - CALL fn'file_conf_path_find_helper_set'default'paths(paths$=final'paths$()) <<paths$>>
DIRECTORY'BSI:11172: ?Undefined named parameter: - CALL fn'file_conf_path_find_helper_set'default'paths(paths$=final'paths$()) <<paths$>>
INVDESC'GEN:171521: ?Undefined named parameter: - aryst.meta'hash$ = fn'hash_ordmap_varstr'x$(type=6%c $key=$dlg'invdesc_xtr'linked'items_meta()) <<$key>>
Code
FUNCTION fn'file_conf_path_find_helper_set'default'paths(paths$() as FN'FILE_CONF_PATH_FIND_PATH_STRUCT,dummy=0 as b1:OUTPUTONLY) as f8
...
FUNCTION fn'file_append(outfile$ as s0:INPUTONLY,aryct as f8:INPUTONLY,ary() as FILE_APPEND_STRUCT,clear'outfile=1 as f8:INPUTONLY,formfeed=1 as f8:INPUTONLY) as f8
...
FUNCTION fn'hash_ordmap_varstr'x$(type as b4:INPUTONLY,$key() as ordmap(varstr;varx),dummy=0 as b1:OUTPUTONLY) as s0
(I'm also getting some unrelated spurious errors which appear to be artifacts of the LSX logic, but I suspect you won't see those in a standard compile.)
Are you sure your version doesn't have the above errors? Is it the case they weren't being spotted?
Wait, the two LSX files you sent appear to have been generated by a much older version of the compiler -- 6.5.953 rather than 6.5.978 (at least according to the LSX header). Perhaps that was by design (because the latest compiler fails to generate a good LSX due to the errors?), but it certainly explains why the above errors are still in there. It may also explain the other errors I'm getting in compiling the LSX. Maybe we should try again with LSX files created by the latest compiler. (I think the LSX shouldn't be too affected by syntax errors in the compilation.)
Ok, the new set it definitely different, and has at least one example of a spurious "undefined named parameter" error. Let me investigate and get back to you ...
This contains compiler edit 979, which isn't actually any different at the source level, but I've dialed back the C compiler optimization, which seems to have eliminated most of spurious errors. (There are still some, but they appear to be due to some problem specific to the LSX; not yet sure whether it's in the LSX itself or in the interpreting of the the pseudo-include operations, but it is eventually losing track of the nesting level.) If this actually solves the problem, it's going to lead to a painful investigation into compiler optimization in order to try to figure out whether it's a problem/limitation in the C compiler optimization related to the size and complexity of the source code, or a problem in the source code that only gets exposed with certain optimizations. But the difference in compiler speed seems to be negligible.
The implementation effectively adds an additional outputonly parameter to the parameter structure, allowing the function to pass back the value into an internal variable set up by the compiler when you use the dot prefix for calling a function.
That seemed like a good idea, except in this scenario, where the function tries to XGETARG one more argument than is declared.
Here's an update which fixes that problem by treating any XGETARG operation beyond the declared parameter list to be allowed (within certain limits)...
It doesn't fix the problem where you try to use the implicit returned value of a function that you pass more arguments to than it declares. I think that may just need to a documented limitation, but it's sufficiently rare/obscure that it isn't urgent. And at the rate we're going, I wouldn't be surprised if this isn't the end of your bug reports!
This is a quirky. Not sure if it's really a compiler bug or just a very confusing set of overlapping conditionals and ++includes. Probably too complicated to discuss here productively - I'll email you instead. But in the meantime, I'm curious whether adding /igoo has any effect on it. (All of your previous examples add that switch, and that's one that will affect the LSX file.
Interesting. The lingering question in my mind is why the /igoo switch solved the problem when the ++IFNDEF <symbol> test at the top of the include file didn't. Unfortunately it's not the easiest study case (with over 2700 functions and over 7000 ++include statements nested up to 10 levels deep!!!). But I would be curious to see a the actual source for that one fnpayment.bsi file (since the way it got rendered into the LSX has left me confused).
This was a development environment I don't use very often and there were some issues in the miame.ini with some missing ersatz definitions. So, perhaps the missing includes caused all sorts of chaos.
Right. I failed to extend the compiler fix in edit 978 to cover the DEFXCALL / XCALL case. I think this is resolved now in 6.5.1715.5 (compiler edit 981) ...
Hi, It seems the new compiler don't like xcall arguments with arrays where the element number have spaces around, like: xcall xtree,er,ec,array( 1 ), ...
I know, it would be stupid to write that kind of code, but LEO does and I can even fix it there, but thought that should mention this considering the change of behaviour and considering it's not a real error.
As an aside, lovely, the new XTREE validation via SBX, thank you.
Last edited by Jorge Tavares - UmZero; 22 Apr 2206:54 AM.
Both of these compile because DEFXCALL and caller match.
My concern is this requires the programmer doesn't make a mistake in setting up the DEFXCALL. It seems like the compiler should force you to use an array named parameter in the DEFXCALL definition.
Ver: 6.5.1715.7
Last edited by Stephen Funkhouser; 22 Apr 2209:35 PM.
