This expansion was causing a big blow-up in the code, as things like:
VAL [2][1]INT as IS [[0,1]]
were getting transformed into:
VAL [2]INT n0 IS [0,1]:
VAL [2]INT n1 IS [0,1]:
VAL [2]INT n2 IS [n0[0], n1[1]]:
VAL [2][1]INT as IS [n2]:
Or something similar -- the inner arrays were pulled up into multiple definitions that were then subscripted, because the first pull-up did this:
VAL [2]INT n2 IS [[0,1][0], [0,1][1]]:
and then the inner arrays got pulled up again, separately. The change hasn't immediately broken anything, but I haven't fully tested it yet
At the moment, the information is only needed in the parser, which must define recursive names before parsing the body of the function. But in future, we should keep the information when the function becomes a proc, and then the C/C++ backends may need to use it (for example, when calculating stack space usage)
For example, a call like foo(6, cs!) will have cs! pulled up, iff cs was of type CHAN X. If cs was of type CHAN! X, nothing is done (and the needless direction will be removed later on).
This was causing a problem in the C/C++ backends, where the slice function call was having _sizes appended to it. So now we pull up anything that results in an array, or is a slice.
One of the tests fails at the moment because the specification node has two entries associated with it in the flowgraph. One is the scope-in and one is the scope-out. I think the analysis is currently picking the scope-out node and looking beyond that, where -- surprise, surprise -- the variable is not used again. So I need some easy way of telling the flow analyses which of the two nodes I want to start from, in this case and other ones where I also add two nodes related to the same point in the AST.
This makes cgtest82 work, although I'm not very happy with it as a fix. I'd
rather have a way of ensuring the state's definitions are kept up to date when
we change something in the AST.
This fixes the AST, parser and typechecker, and adds a pass to
transform Result back into Abbrev, but doesn't transform Initial yet.
(It actually works for trivial stuff anyway, but it won't do the right
thing for complex types or PROC parameters.)
It appears (to me) to make sense to support INITIAL/RESULT reshaping
and retyping too, so this does.
Refs #42.
All the passes now have their information (name, pre-requisites and post- properties) stored at the point where the pass is declared, which means the pass lists are just a simple list of pass functions.
The main consequence of this change was that the tests had to be changed. Now, instead of taking a "pass applied to data" item (type: PassM b), they take both the pass (type: Pass) and source data (type: b), and apply them later. This was the decision that involved the simplest changes to the existing tests (simply unbracketing the application of the pass to the source). I also had to include a few old-style versions though (testPass', testPassShouldFail') for where the functions were being used to test things that weren't actually passes (mainly StructureOccam).
Fixes#48