new reusable functions for using PathConfig

[jurgenvinju]

• this branch is a pure extension of another cleaner PR branch that was already merged: clean-factor-path-config
• this branch adds basic functionality to compute file names from module names and module names from file names
• a reusable function for computing the latest relevant source file or binary file or library file based on the PathConfig and the timestamps of the relevant files
• the parameters for the above functions are computed from a LanguageFileConfig constructor, that explain which extensions, prefixes and filename escapes to use.
• this code is all Rascal-independent; should work for any DSL that can be configured using a LanguageFileConfig. The default is set for Rascal's file extensions and prefixes (.tpl, $, /rascal), however.
• this code is robust for any loc scheme; however it is important that the entries in srcs and libs are directories (so mavenized or jarified if originally a jar).
• uses a new and robust inverse of Location::relativize: namely Location::resolve. Resolve is about finding the right prefix that a relative path belongs in. Resolve on a single location is simply outside + relative.path, but when a list of path folders is given IO::exists is used to find the right prefix and then returning the full loc as outside + relative.path.

An overview:

module name (str) to file path (loc)	file path (loc) to module name (str)	PathConfig field used
srcsFile	srcsModule	srcs
binFile	binModule	bin
libsFile	libsModule	libs

[rodinaarssen]

We should probably revisit #2265 after finishing this PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 47%. Comparing base (31f629d) to head (fe06925).

Additional details and impacted files

@@           Coverage Diff            @@
##              main   #2270    +/-   ##
========================================
  Coverage       47%     47%            
- Complexity    6476    6477     +1     
========================================
  Files          768     767     -1     
  Lines        63807   63701   -106     
  Branches      9526    9511    -15     
========================================
+ Hits         30252   30257     +5     
+ Misses       31267   31159   -108     
+ Partials      2288    2285     -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PaulKlint]

Where did you move the Manifest-related code from util::Reflective to?

[PaulKlint]

Where did you move the Manifest-related code from util::Reflective to?

[jurgenvinju]

Where did you move the Manifest-related code from util::Reflective to?

I thought I kept it where it was? Just added @deprecated to those functions.

[jurgenvinju]

This is ready to merge:

• the main additions in util::PathConfig are conservative but comprehensive API to map source to binary files and back through searching in PathConfig srcs and libs
• no changes in util::Reflective
• some side-damage discovered while testing; spaces and newlines and types for local variables
• accidental removal of the unused Task library (we communicated this with @anyahelene years ago already, but never took the time).

[jurgenvinju]

@PaulKlint Where did you move the Manifest-related code from util::Reflective to?

This branch makes no changes to util::Reflective. I think we removed that code earlier because it was not used anywhere by anybody. All the Manifest and pom related code is now in PathConfig.java

[toinehartman]

I like this. I don't really understand what motivated these changes, but I think especially the LanguageFileConfiguration will provide some nice consistency when working a lot with paths and module names.

[jurgenvinju]

The motivation is the requirement that util::PathConfig can stand by itself, as a library module for configuring any file-based language processing tool; Notably independent of the Rascal-specific code in util::Reflective.

Without this semantics of path search and file mappings readily available, the syntax of PathConfig is a lot less useful.

To make sure these functions are useful and complete in some sense, we made sure that they could be used to implement the rascal type checker and Compiler. There is no plan to replace the current rascal implementation, however. Afaik.