mnbujold / c415-compiler Goto Github PK

As per the discussion in class today, we need to be able to escape any characters and (I think) let the interpreter deal with what those symbols mean.

Test these changes on the cp1/21.pal test program.

Man page needs to be written.

We get a segmentation fault in g04.pal. Not good. Maybe we should have an "exit gracefully" wrapper ...

Also get a seg fault in:
g07.pal

In test se10.pal, on line 42, we do not catch the error of an array being assigned to an integer variable.

In Piotr's 01.pal test, the second illegal character error is displayed at the end of the program, rather than at the line it should.

Go through marking guide and re-check all tests against CP1.

In test se08.pal, we do not catch a parameter's type being redeclared as another type.

characters are not compatible with arrays of type char with a size of 1 (starting a 1, since strings need to start at 1).

See test g01.pal.

Lexer currently only passes on id and strings. Make sure it passes on integers and reals as well

We are only catching the first of the three errors in 23.pal, even though those errors should not be very difficult to find and recover from.

The lexer should remove the apostrophes at the beginning and end of strings before it sends the string to the grammar.

Source: 1.pal

compiler complains that function nowork is undefined, because the function declaration was screwed up. We need to add nowork to symbol table anyways, and flag it as being invalid

For some reason, the built-ins are spread between level -1 and level 0, thus reducing the number of levels of scope that we can support from 15 to 14.

Implement Symbol Table

Change symbol_rec so that all symbols have a struct type_desc. This will make type checking waay easier than having to check which object class it is, then get the tyep description based on that object class, etc...

Run on test 9.pal.

Changed anonymous unions to defined unions so you can do thigsn like
union foo {
};
bar (foo), instead of casting void pointers around like a nut

I am changing the way that variables are pushed onto the stack, so we can actually keep track of the address of each variable (it was not actually tracked before). So this will PROBABLY break your array access code. But it's for the best, right?

I'm guessing this is because the syntax tree isn't finshed yet? I can't generate code for this

When do we need brackets to ensure order of operations?

Look into what order we evaluate expressions via the many operators, and what order we SHOULD have.

On nt01.pal, the line number is off by 1 after the big block comment at the top. I suyspect it's because we forget to count the newline at the end of the block comment

We should do our best to follow good coding practice and comment code when appropriate.

A parameter of a scalar list type is not comparable with a constant in that same scalar list.

See test g03.pal.

For comments, print out all the line numbers instead of just printing out the last line of the commment at the beginning

ie:

{8} { asdgasdgasdgasgas

.....

}

Newlines are being printed out and added to the line count for no reason
look at 0.pal

In se11.pal, we allow the assignment of the return value of a function to outside of that function's scope.

In test g11.pal, the '/' operator does not allow for division by integers, according to our compiler.

Is this actually legal?

We need some sort of file types for the input and output variable in the program header.

Check the valid chaining of conditionals and usage of semicolons and ends in conditionals.

Function return types must be simple types as alluded to here:
https://eclass.srv.ualberta.ca/mod/forum/discuss.php?d=127507

Arguments to var parameters must be assignment compatible both ways as specified here:
https://eclass.srv.ualberta.ca/mod/forum/discuss.php?d=127510

Probably because of the null end character (?), strings do not actually have the same size as arrays that should have the same size.

Vars are not assigned any values from the constant folding we do...which obviously makes our constant folding useless..
]

This happens occasionally with some programs...it duplicates the first line of the program when parsing.

The compiler still produces a .lst file when the -n option is used, contrary to specifications (although the entire listing is not printed out to stdout - so that part works).

read, readln, write, writeln
intger, real, character, string io

ord
chr
trunc
round

succ
pred

odd

abs
sqr
sqrt
sin
exp
ln

true
false
maxint
minint

In Piotr's 03.pal test, we only catch the first error caused by incorrect comment formatting. This may be related to the invalid character bug.

Test g20.pal, on line 159, has a string with many escaped characters. What is the length of the string when assigning it to another string?

Having non escaped new lines (eg the user hitting the return key) within a string will screw up the line count; these are not counted towards the newline and so the line count will be off by however many newlines there are in there

Running the compiler on 8.pal causes "scope too big errors" on level 14 (procedure layer14()), which it should not.

Turns out we're not doing constant folding. Either that, or the syntax tree does not actually return teh folded constant value and instead returns the 2 constants

Our compiler adds an extra empty line to every line in the 0.pal listing and output. Doesn't seem to happen with the other tests.

Our compiler does not catch a constant (return value) being used as a var parameter in test se01.pal.

In test se15.pal, variable declarations of the form

var name : name;

are not caught. We need to check the scope of the type of variables finer.

On some test, the '^' symbol does not correctly indicate where the error occurred on the line. The caret is in the correct location for our tests (0.pal and 1.pal specifically), but not for all of Piotr's tests.

If more than one error occurs on a single line, all those errors have the same line number. However, subsequent error numbers and the total error count are still correct.

The following code on line 20 of 0.pal:

bob, joe : array[1] of array[boolean..{LOL}] of char;

is not being caught as an error.

In 9.pal, a comparison between a variable and a constant of the same scalar type incorrectly gives an "operands are not compatible" error.

type
a = blah blah blah
b = array [a]
gives an error
This is probably because of how compiler.y reduces the rules

It appears that operators are still sometimes not checking if an operand is of type TC_ERROR and should be ignored rather than reported as an error.