Skip to content
This repository has been archived by the owner on Dec 11, 2023. It is now read-only.

Create Branch for Failing Syntax Tests #41

Open
tajmone opened this issue Jan 16, 2022 · 2 comments
Open

Create Branch for Failing Syntax Tests #41

tajmone opened this issue Jan 16, 2022 · 2 comments

Comments

@tajmone
Copy link
Contributor

tajmone commented Jan 16, 2022

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 dedicated fail-tests branch to store all syntax tests that fail, in a dedicated folder like Tests-Fail.

Then, I could create all failing tests in the Tests-Fail/ folder, and create a PR on the dedicated fail-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 the Tests-Fail/ folder into Tests/, commit them to main and remove them from the fail-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 and fail-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.).

@p4t5h3
Copy link
Owner

p4t5h3 commented Jan 16, 2022

[…] 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.

@tajmone
Copy link
Contributor Author

tajmone commented Jan 17, 2022

Failing Tests Branch on My Fork

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants