thedan64 / limonite Goto Github PK

Basically, don't require llvm to be installed (compile time flag) when building. and otherwise set up code gen folder structure and trait to allow for different backends.

As a test of this you could move the print ast flag to instead to just be a backend

removed skip to end of the line because it wasn't also compatible with matching braces (e.g. ([`{'<" ), which would make it not work particularly well in most cases.

Add this back but with proper support so that the parser can hit an error without barfing immediately.

O(n) operation when it could be O(1) if we were iterating rather than trying to directly index each char

Currently we're creating new Strings which I believe allocates more memory. The ideal but difficult optimization is to use slices from the original String but would probably require a lot of rework to get associated lifetimes to work together.

Your dependency file specified a branch or reference for https://github.com/TheDan64/inkwell, but Dependabot couldn't find it at the project's source. Has it been removed?

View the update logs.

for now, variables are required to be initialized when they are declared. This is pending static analysis to detect when variable are first accessed to ensure uninitialized variables are not used.

var i = 1
while i > 0,
        >> C
        i -= 1

returns filename:0:0 There were two indents in a row, 1 and 1 x2 but the code is valid and has valid codegen

Blocked by Inkwell lacking support for versions other than 3.7 at the moment. Will try and update as many newer versions as we can.

such as MinusEquals, PlusEquals, etc.

What feels right to me, would be a preprocessor which would e.g. consume i += 1 and produce i = i + (1) (the parenthesis are to ensure an arbitrary expression for the rhs gets evaluated before infix operating with the i). This would mean the general parser would only have to handle Equals for assignment.

The problem with wrapping the rhs in parens means it would have to consume all tokens until the expression ends, which means it has to know how to parse expressions. We may (?) be able to separate expression parsing from the parser impl first, since an expression shouldn't need to depend on any program state, like indentation or context.

Apparently for the last year. Would like to have an up to date on overall test coverage. Requires fixing the travis build script.

pending discussion of what it should look like.

Now that Inkwell is starting to shape up, we should get our backend updated to the latest Inkwell. May end up providing valuable insights for Inkwell design as well. I've started this in the inkwell_future branch

We currently fail to parse some characters(ie y̆) when they have additional unicode modifiers. The unicode-segmentation crate should be able to help us here.

I've already started looking into resolving this on my llvm branch, but I'll be busy with finals and such for a while.

Currently lexer error messages are passed up to the parser, which is probably fine. But I think the parser and code generator should have a format and possibly a supporting format function decided for how to format errors (and eventually warnings). We currently have like 2-3 different functions, I think, all of which are for different formatting?

Also, there should be discussion on whether or not we're handling errors the right way.
Current MO for both the parser and code generator is to just print the error right away and return None. Iirc, the None will just be propagated back to the top level and disregarded. I personally like how this works, but I'm not sure if we should be doing it this way.

The alternative, I suppose, would be to use Rust's Result as intended for error handling, to propagate the error message to the top level and print it there.

I'm kinda more in favor of keeping it as is at the moment, but I'd also like for us to consider any benefits there might be by switching to the Rust practice/standard of using Result for error handling.

We're going to start with a strict 1to1 mapping between the names of things in a given scope. Ideally though, variable shadowing is possible so allow this.

• Create library: Inkwell
• Have limonite use inkwell

Your dependency file specified a branch or reference for https://github.com/TheDan64/inkwell, but Dependabot couldn't find it at the project's source. Has it been removed?

View the update logs.

With rustc-serialize now officially deprecated, we should remove it. If there is functionality we need replaced, Serde should work as a replacement.

Currently, we're still using Travis' legacy system

The slog crate seems like the standard for logging in rust these days. We should update from log and env_logger to slog.