thelegendofmatanui / shoefitter-dx Goto Github PK

The Statement class should be able to provide where in the source it originated. However, calculating this for each instance upon construction would likely be wasted effort. Instead, Statement should be able to calculate its source range from its members when requested, in a getter.

Tested so far:
ONUA - O002
BULL: BL02

Move class parsing from Parser.Parse into a dedicated ParseClassStatement method.

Not a huge problem for characters, but for levels, it'll definitely be necessary to be able to select and focus on objects. Usually F in Maya and Unity so should probably just be that,

Implement a method OSIFile.Write(BinaryWriter writer).

See the OSIFile constructor for reference.

LSSInteractive and the OSI Browser should become Document-tier tabs in the Window, and they should be opened from a Tools menu in the Window.

This involves changing the OSI Browser to ask for an OSI filename when it is opened.

Animations s001 and s012 for BSPD do not render correctly in SFDX.

Video of how they should look:
https://cdn.discordapp.com/attachments/746067604480721520/756592383579127889/2020-09-18_14-06-08.mp4

These should follow standard C-style syntax.

This involves working on:

• The scanner (for keyword)
• The parser (adding a ForStatement)
• The compiler (compiling the ForStatements)
• The documentation in SAGESharp/LSS/readme.md

Right now, the LSS compiler does not support compiling instantiations (new ClassName(params...)).

This call should emit a CreateObject instruction followed by a Dup instruction and the rest of the constructor parameters, and then Pull the new instance, get the constructor member function, and then JumpAbsolute.

We will use a mangling of Java and C# syntax here, and assume the iterable is an array.

foreach (var i : things) {

}

Just like #20, this will involve work on the scanner, parser, compiler, and docs.
For an example compiled enhanced for loop, see https://github.com/TheLegendOfMataNui/Optional-OSIProject/blob/master/OSIProject/class/l4_visn_puzzle.osas#L301

BSPD, s005 and s006. Apparently caused by a -1 boneID.

Add support for compiling superclass properties and methods into child classes.

There are a few things to be aware of:

• Declaring a property in a class which inherits a property of the same name is a syntax error.
• Declaring a method in a class which inherits a method of the same name is called overriding, and is perfectly fine. Overriding does not take method signature into account - just the name.
• Overridden methods are not inherited from superclasses.
• Methods inherited from a superclass point to the same bytecode as the superclass's method, yet the bytecode offsets are not known at compile-time. This means that OSIFile.MethodInfo needs to store a 'source' MethodInfo that has a value when the MethodInfo is using the bytecode of another MethodInfo.

The LSS compiler should embed source filenames in the generated OSI, and emit LineNumberAlt1 instructions. (See https://github.com/TheLegendOfMataNui/sage-js/tree/master/res-osi)
There should also be a compiler option to disable this.

BULL never retracts his neck, even though this is the default state in game. This also applies to C302 where he's supposed to extend it, but it's otherwise always extended in SFDX and exports.

Create a new C# desktop project in the Shoefitter-DX solution that calls the compiler in the main assembly.

This CLI should:

• Have command-line arguments for all the compiler options at any given time
• Output compile messages in a format that is both machine- and human-friendly

All LSS compile options (that is, all input that is not source files) should be contained in one options class that is passed through the scanner, parser, and compiler.

A button should be added to LSSInteractive that saves the most recently compiled OSI to a file.
This button should be disabled if the user has not compiled an OSI, when the scan or parse buttons are clicked, and when the compile button is clicked and compilation fails.

The LSS compiler (including the scanner & parser) can currently output SyntaxError instances. However, they should also be capable of outputting messages that are not necessarily errors.

At first glance, it looks like we should incorporate an existing logging solution. However, we also want to store additional information, such as a machine-readable message code and source location, so a general-purpose logging library won't cut it.

Replace the SyntaxError classes with a CompileMessage class, which should include:

• The textual message
• A textual 'message code'
• A source location (source filename if any - we don't have a way to utilize this yet, but we will, character offset, and character length)
• A severity (compiler crash, user error, warning, info)

Color expressions should use the keyword rgba and parse like static functions, except they emit PushConstantColor8888 instructions, and then for each channel if the value is not a constant, set it immediately after the constant.

Example LSS:

var myColor = rgba(255, 128, 0, this.alpha);

Right now, the LSS compiler simply throws an exception when it encounters a syntax error. This isn't desirable - we want to provide feedback on as much of the code after the error as possible, without emitting extra 'phantom' errors that only exist because of a previous syntax error.

The LSS compiler, parser, & scanner need to support panicking & synchronizing when it encounters a syntax error that it cannot tolerate. For the scanner, this will likely involve skipping ahead to the next whitespace. For the compiler & parser, this will likely involve throwing a custom exception class, and catching it at the statement level, and then removing the instructions emitted for that statement.

For more information about panicking & synchronizing, check out http://craftinginterpreters.com/parsing-expressions.html#panic-mode-error-recovery

Right now, we use a 3-line sequence of new BCLInstruction, .Size, and Instructions.Add() all over the place that could easily be replaced with a function that does all that and returns the size.

The ++ and -- operators are going to be a pain to implement and only save a little bit of typing.

Remove them from the TokenType enumeration and remove the related parsing & compiling code.