Parsing Constraints and SkriptParser split + refactor #8198
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The SkriptParser class is a sprawling mess. There's multiple versions of the same method doing different things, 7 different ways to parse something, and a very limited ability to tell it what exactly you want it to parse. You can supply an iterator of syntaxes to attempt, but that can become hard to construct if, say, you want a section that doesn't allow functions, but within that you want another section that only allows things that return String. These constraints are hard to manage and are fully the responsibility of the caller, who may not be aware of existing constraints.
Constraints also exist in the form of a set of bitmap flags, which are clunky and poorly documented at the best of times.
Solution
The goal of this PR is to provide a new class, ParsingConstraints, that holds all the information necessary to constrain a parse to the user's desire. It provides control over whether functions are allowed, literals, non-literals, and even provides methods to only include or specifically exclude certain syntaxes via their class.
Since this requires a significant rework to the internals of SkriptParser, I am also addressing the messiness of the class. I have moved many methods out into other classes, such as the string search/check methods to StringUtils, and a variable parsing method to Variable. I've also added FunctionParser and ExpressionParser classes that are SkriptParsers of their own that specialize in parsing specific syntax types. This significantly reduces the load of the single SkriptParser class and reduces the complexity and mess of the parser. Many helper methods and other ways of reducing complexity are also being implemented to help out.
This is still very much a work in progress and I am currently in the process of duplicating all the features of SkriptParser. Reviews are welcome, but know that all of the code is subject to change as I continue. I would love high-level feedback on the design that doesn't focus on details, though.
Testing Completed
Supporting Information
I am targeting this to be ready for merging just after the 2.13 release.
FunctionParser is outdated and needs to be updated to reflect the changes to function parsing in 2.12.
Completes: none
Related: none