Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LSP: fix hovering over a string #26177

Merged
merged 5 commits into from
Oct 30, 2024
Merged

LSP: fix hovering over a string #26177

merged 5 commits into from
Oct 30, 2024

Commits on Oct 30, 2024

  1. Handle type query domains (and emit errors when parts are queried) 

    Signed-off-by: Danila Fedorin <[email protected]>
    @DanilaFe
    DanilaFe committed Oct 30, 2024
    Configuration menu
    Copy the full SHA
    f1f6afb View commit details
    Browse the repository at this point in the history

  2. Treat passing to unknown type as instantiation 

    This is important for cases in which type queries need to be populated.
They are only populated from substitutions, but substitutions
are not created for completely unknown formals, because
prior to this commit, a completely unknown formal can be
passed to without instantiating (i.e., without substitution).
This commit changes that.

Signed-off-by: Danila Fedorin <[email protected]>
    @DanilaFe
    DanilaFe committed Oct 30, 2024
    Configuration menu
    Copy the full SHA
    0b563e5 View commit details
    Browse the repository at this point in the history

  3. Reject candidates that fail due to inability to infer type queries 

    After computing a formal type, we traverse the formal AST to find
out what the type queries are. This may fail (e.g., if the formal
AST doesn't match up with the instantiated type). Thus, the post-
query type will be unknown. This is an error, since it indicates
that the type queries couldn't be properly made sense of and
incorporated into the final type info. In such cases, reject the
candidate.

A concrete example: formal ?k*?t, actual int. The initial type
is unknown; after instantiation, the formal type is int. When
resolving queries, we can't figure out how to spit init across
?k*?t, leaving type queries unknown. When re-combining the formal
type with query info, ?k*?t is again unknown since the queries
were not known. This means we couldn't instantiate ?k*?t with int,
and the candidate is rejected.

Signed-off-by: Danila Fedorin <[email protected]>
    @DanilaFe
    DanilaFe committed Oct 30, 2024
    Configuration menu
    Copy the full SHA
    f161cc4 View commit details
    Browse the repository at this point in the history

  4. Handle unknown actuals (needed for out-formals) in builtin functions 

    We have some builtin functions like type/param casting to string,
handled by the compiler. They did not expect `null` actual types,
but this can happen sometimes (e.g., when the call site allows
for the possibility of `out`-formals being matched with the actual).
This commit adjusts the code to handle that.

Signed-off-by: Danila Fedorin <[email protected]>
    @DanilaFe
    DanilaFe committed Oct 30, 2024
    Configuration menu
    Copy the full SHA
    3812cb8 View commit details
    Browse the repository at this point in the history

  5. Skip unknown arguments when building ranges. 

    Resolving ranges boils down to resolving a function call. Dyno
skips resolving normal function calls under certain conditions
(e.g., if the argument types could not be inferred). However,
it doesn't do so for ranges, which made it possible for 'Unknown'
or otherwise invalid actuals to slip into the call resolution
process. This commit adjusts the resolver to re-use the skipping
logic.

Signed-off-by: Danila Fedorin <[email protected]>
    @DanilaFe
    DanilaFe committed Oct 30, 2024
    Configuration menu
    Copy the full SHA
    9d0d5e5 View commit details
    Browse the repository at this point in the history