new reusable functions for using PathConfig #2270
Conversation
…he helper functions for computing source and target locs and modulenames using PathConfig instances
…rametric functions for PathConfig processing
…in PathConfig.java
|
We should probably revisit #2265 after finishing this PR. |
This comment was marked as outdated.
This comment was marked as outdated.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2270 +/- ##
========================================
Coverage 47% 47%
+ Complexity 6335 6334 -1
========================================
Files 762 761 -1
Lines 62974 62868 -106
Branches 9397 9382 -15
========================================
+ Hits 29909 29930 +21
+ Misses 30849 30722 -127
Partials 2216 2216 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| return replaceAll(relative.path[1..], "/", fcfg.packageSep); | ||
| } | ||
|
|
||
| // below we have some core tests of the above features |
There was a problem hiding this comment.
Good to see these tests, but this violates our current test organization.
I would expects then in tests/libraries/PathConfigs
There was a problem hiding this comment.
I've been slowly moving library tests to the library since a few years, because the tests are documentation for the users. The current tutor displays the bodies of tests in the API documentation (while normal function declarations are only shown by their signatures.)
| = libsFile(qualifiedModuleName, pcfg.libs, fcfg); | ||
|
|
||
| loc libsFile(str qualifiedModuleName, list[loc] libs, LanguageFileConfig fcfg) throws PathNotFound { | ||
| loc relativeFile = |relative:///| + fcfg.targetRoot + replaceAll(qualifiedModuleName, fcfg.packageSep, "/"); |
There was a problem hiding this comment.
no that has been there for a while. It is a scheme without semantics (no readers or writers), except that it is always the output scheme of relativize and the input scheme of resolve (the inverse of relativize).
relative:/// locations can be highly useful to use the operations like loc[extension="bla], or loc + str or loc.parent without having to resort to string manipulation.
There was a problem hiding this comment.
Eventually you use either resolve(absoluteLoc, relativeLoc) or absoluteLoc + relativeLoc.path to get a normal loc again that can read and write stuff.
jurgenvinju
changed the title
I thought I kept it where it was? Just added @deprecated to those functions. |
Uh oh!
There was an error while loading. Please reload this page.