Open tajmone opened 2 years ago
[…] but I've postponed this work until the syntax includes the version: 2 key, to be sure all tests are ST4 engine compatible.
So this can be considered blocked until #40 is closed.
I've now created a dedicated fail-tests
branch on my fork, where you'll find the Tests-Fail/
folder where I'm starting to add syntax tests that contain errors.
Because I've created various PureBasic syntax definitions for code highlighters in the course of the years, I have lots of test files covering edge cases and odd syntax quirks that are considered valid by the PBCompiler and the native PB IDE.
I think that this syntax should adhere strictly to compiler code, and accept the syntax quirks that are not usually found in other languages. As for the many problems with the native IDE not being able to correctly highlight valid code, we should instead capture the syntax as it should be.
There are tons of problems which need to be addressed with the current syntax. When I have time, I'll start to add the tests in the new fail-tests
branch, open an Issue for each element that is problematic and then start working on the fixes — in most cases, I only need to copy and paste my original contexts RegExs from my old Sublime PureBasic package, because although it wasn't feature rich it did cover in details those quirks which I was aware of.
When I'll open an Issue I'll specify whether I'm also planning to implement its fix, so we don't end up both working on a same feature.
I have a suggestion to handle failing syntax tests, using a strategy that I've employed in the past already.
Since in the
main
branch all tests need to pass, because of the CI/Workflow validation, it would be a good idea to have a dedicatedfail-tests
branch to store all syntax tests that fail, in a dedicated folder likeTests-Fail
.Then, I could create all failing tests in the
Tests-Fail/
folder, and create a PR on the dedicatedfail-tests
branch, so that we're able to keep in the repository all problematic tests which need to be addressed, and as the syntax is fixed, we can then move the failing tests from theTests-Fail/
folder intoTests/
, commit them tomain
and remove them from thefail-tests
branch.I actually have a number of failing tests that I just need to clean up and place somewhere, before starting to work on the fixes — but I've postponed this work until the syntax includes the
version: 2
key, to be sure all tests are ST4 engine compatible.The reason I like this approach is because it allows to keep track of all syntax problems, edge cases that need to be addressed, and at the same time give respite in terms of having to fix them at the syntax level — the failing tests are there in their dedicated branch, and can be addressed whenever one wishes to, and switching between the
main
andfail-tests
branches is very easy, as well as keeping the latter in synch with the former via simple rebase operations (and see if any changes to the syntax might have fixed some failing tests).Sometimes I also use this system to pin-down new syntax scopes which I didn't have time to implement (e.g. handling sub-scopes like distinguishing between decimal, octal, hex and binary literal numbers, etc.).