fix/parser storage stability - #2759
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2759 +/- ##
=======================================
- Coverage 45% 45% -1%
- Complexity 6724 6725 +1
=======================================
Files 841 841
Lines 67058 67058
Branches 10021 10021
=======================================
- Hits 30803 30797 -6
- Misses 33870 33873 +3
- Partials 2385 2388 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
… such that the directory provided at the top-level of the recursion must at least exist, and lower levels do not check existence because .ls already guarantees existence modulo races on disk
DavyLandman
left a comment
There was a problem hiding this comment.
Looks good, but I found 1 case where the param wasn't set for down-stream calls.
|
7e1bcc1 to
461682b
Compare
|
|



This PR is to help diagnostics of issues during parser storage (and the implicit parser generation process below it).
One of the main issues we encounter when using the parser storage features is incompleteness of the specification as a whole (missing modules which are imported or extended but not represented). A bit of incompleteness improves efficiency (a lot), so users filter their lists of modules. This may lead to missing syntax rules eventually. The current PR makes filtering a builtin feature, and reports missing modules as warnings so things do not go south implicitly anymore, and finally makes underlying filesystem API fail faster in the presence of non-existing folders.
PathNotFoundif the provided folders do not exist This fails a lot faster and a lot clearer than the dozens of missing modules you get from that. This helps when using thelibscheme which is not implemented anymore.