Carlyle-Foster

now that i think of it, we should be able to confine comment parsing entirely within whitespace parsing, can you think of any exceptions?

> i don't think we'd have to look for `;` all the time, unless there's some de facto standard for for closing comments within a line comments can never appear...

i'm not sure if this should be closed yet, i found [this](https://datatracker.ietf.org/doc/html/rfc822#appendix-D) out in the wild, it's VERY old but it's usage of comments really make sense, if newlines are...

i might just have to bite the bullet on this one and replace all the simple WS parsing with a custom function that parses WS while transparently skipping comments

```;``` isn't the main delimiter, we do normally just consume until we hit a newline, ```;``` is only a delimiter because for some reason i though having two comments on...

> one note here is that I don't think comments are actually allowed anywhere except at the end of a rule so rather than `here ::= "b" | and here`...

> I think we're talking about the same thing but just in case, here's the **current** behavior for bnf grammars > > ``` > ::= | > ::= 'A' |...

i also ran into this

bypassing the assertion mentioned in the output of test_case_1 (`src/llvm_backend_const.cpp(769)`) results in a codegen failure similar to test_case_2: ```bash LLVM CODE GEN FAILED FOR PROCEDURE: test_case_2::main define void @"test_case_2::main"(ptr noalias...

@Paul-Andre bypassing the assert in that simpler case doesn't fail codegen but instead silently removes the expression, u can tell if u try to use the expression as in: ```odin...