[Chapel Merge] Dyno/CLS: Un-xfail CLS tests that can reasonably work

Notifications Commits
1

Branch: refs/heads/main
Revision: f0dd3ea73b8de9e792a6113987e6613b761b2e1f
Author: DanilaFe
Link: Dyno/CLS: Un-xfail CLS tests that can reasonably work by DanilaFe · Pull Request #28484 · chapel-lang/chapel · GitHub
Log Message:
Dyno/CLS: Un-xfail CLS tests that can reasonably work (#28484)

Closes CLS: Enum values print as dyno ids instead of their name · Issue #25114 · chapel-lang/chapel · GitHub.
Closes [Bug]: Type inlay hints are printed incorrectly for several types · Issue #25113 · chapel-lang/chapel · GitHub.

Today, CLS testing has numerous xfails, which as the name suggest are
expected to fail. They reflected an ethos in which the resolver was a
very unstable tool, and as a result, it was okay for things to not work
as expected in all cases. However, the resolver today is (though still
unstable) relatively robust, and an inspection suggests that the tests
that are xfailed fail for reasons that can be addressed.

  • Some tests require type printing as int instead of int(64). Though
    to preserve the way the user wrote the code, we'd need something like
    dyno: consider tracking type aliasing with QualifiedType · Issue #20914 · chapel-lang/chapel · GitHub, it seems like a fine
    concession to allow printing int(64) for int, since it's precise and
    semantically equivalent.
  • Other tests worked but expected domains and ranges to print their
    substitution enum params qualified (boundKind.both vs both). I don't
    think we've explicitly designed this one way or the other in Dyno.
    Production prints these unqualified, but I think the additional
    information is helpful. So, adjust Dyno to print these qualified.
  • A test expected "go to type definition" to work on a string literal.
    @jabraham17 believes this is uncommon (since most languages don't have a
    library type for their strings), and not a crucial part of that test.
    The original issue (in which the test crashed Dyno when trying to go to
    the type definition of var x = "bla", no longer occurs.

Some tests also failed due to generating invalid Chapel code (e.g.,
relying on default-initialization of owned, non-nilable fields). I
adjusted those tests to generate reasonable Chapel code, and they no
longer produced diagnostics.

@benharsh --- would you take a look at the Dyno changes? @jabraham17 ---
would you please take a look at the CLS changes?

Reviewed by @benharsh, @jabraham17 -- thanks!

Testing

  • dyno tests
  • CLS tests

Compare: Comparing cd394bc2395450868e44eeec6d16f2e18c9426a6...ca452e22caec57f4a7aa5c80c7b969e7b7d12e18 · chapel-lang/chapel · GitHub

Diff:
M frontend/include/chpl/types/CompositeType.h
M frontend/lib/types/CompositeType.cpp
M frontend/lib/types/DomainType.cpp
M frontend/test/resolution/testEnums.cpp
M frontend/test/resolution/testLibrary.cpp
M frontend/test/resolution/testTypeQueries.cpp
M tools/chpl-language-server/test/basic_resolver.py
M tools/chpl-language-server/test/type_inlays.py
https://github.com/chapel-lang/chapel/pull/28484.diff