ilovepi / compiler Goto Github PK

Coverity scan reports a defect in Main of Program Project.

Can fix with a using statement

** CID 1397995: Resource leaks (RESOURCE_LEAK)
/Program/Program.cs: 22 in System.Void Program.Program::Main(System.String[])()
16
17 } while (t != Token.EOF);
18
19 // necessary when testing on windows with visual studio
20 //Console.WriteLine("Press 'enter' to exit ....");
21 //Console.ReadLine();

CID 1397995:  Resource leaks  (RESOURCE_LEAK)
Variable "l" going out of scope leaks the resource it refers to.

22 }
23 }

While our scheme for handling arrays will work... it is less than ideal, and wastes space. There is also a high cost for memory indirection that we pay for in this scenario.

Change to a flat array structure and then allocate the corresponding arrays based on a single offset from the base address.

Support CSE by enhancing the instruction class to have a use-list which catalogs all the instructions that use this result.

After CSE use the use-def-chain to eliminate dead code.

Can be done in a single linear pass in which the the use list of an instruction can be queried, and removed if it has no reference

We insert directly into the basic block's instruction list, but we should be using a BB.Insert(someInstruction) format instead. This will allow us to correctly update the Anchors, which we'll need for Common Subexpression Elimination.

After results have propagated to their destination, there must be some clean up to remove constant expressions, and perhaps even trim constant comparisons. It will be safe to do at this point because there are no unseen instructions or blocks, and Phis can simply be removed.

We should use a remote CI to maintain the compiler on a per commit basis. This will simplify maintenance, and is good practice

I'm not sure what to do with these, but we shouldn't generate them when we do, except for things like arrays

The current parser and lexer on the rewrite branch use a simple error function similar to what Michael presented in his original lecture. There is a case to be made for this design, but a custom exception might be a better choice for maintenance and usability.

Exceptions should provide better error messages about where in the file the error occurs, and what was expected, and what was found.

this will give users a good idea about why compilation fails.

Since we're the users of this compiler, good error messages means we're not savages.
We can use some of the code from existing branches as a starting point, although they rely on an AST for the most part.

We have a lot of things on the TODO list, and should clean them out

Our project needs proper unit tests for all of the lexing and parsing. Mocks may help isolate/encapsulate the test logic.