Expose uses in TModels produced by Rascal typechecker

[sungshik]

Fixes #2165

Integration test succeeds: https://github.com/usethesource/rascal-core-big-tests/actions/runs/27571505385

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46%. Comparing base (6cff72e) to head (e637cb7).

Additional details and impacted files

@@           Coverage Diff           @@
##              main   #2803   +/-   ##
=======================================
- Coverage       46%     46%   -1%     
- Complexity    6722    6725    +3     
=======================================
  Files          839     839           
  Lines        66766   66766           
  Branches      9983    9983           
=======================================
- Hits         30782   30774    -8     
- Misses       33601   33607    +6     
- Partials      2383    2385    +2     

☔ View full report in Codecov by Harness.
📢 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]

Hi @sungshik, the changes look good. But ... do we need this? And I admit that I should have spotted this earlier. In fact, uses is an "internal" field of the TModel, i.e. it used by the Solver but not exposed externally. There are two reasons for this:

• uses can easily be derived from the useDef relation using domain(tm.useDef) for some tm.
• it saves some space by not storing it.
  By the way, similar considerations apply to the fields calculators and requirements: for internal use only.

A cleaner solution would be to create two data types: TModel and ExtendedTModel, where TModel is the public interface and is a subset of ExtendedTModel . We need a discussion on this.

[sungshik]

Thanks, Paul! Summary of the offline discussion (with also Davy, Toine, and Rodin):

• TModel should be divided over two modules. Details: Divide TModel over two modules typepal#51.
• Use values contain more information than just occurrence locations. As such they might be useful outside the Rascal typechecker to define language services.
• However, we cannot think of any such language services right now (and we don't remember what exactly was the underlying reason for uses field of TModel does not contain use #2165). Therefore, at least for now, this PR won't be merged.

[DavyLandman]

I want to add that one of the particular problems with the uses field (also true for the same field in Summary) is that it's only scoped to the current module. While most analysis & IDE features don't care for this constrained module-only-uses view.

We could only find use-cases for the uses field if you would merge the uses of all modules into a single relation/set.