Resolution handler #1068

g-r-a-n-t · 2025-03-28T18:24:30Z

This adds support for ingot dependencies on the file system. It includes significant changes to the resolver that make it more flexible. The new resolver is used in the driver crate to transitively initialize ingots and their dependencies via the init_ingot function. This driver function is used by both the language server and check subcommand to setup the input database. The resolver is also used directly in the tree subcommand to generate a tree representation of dependencies, without the overhead that would come from using the init_ingot function.

Followup items:

Readd support for --core flag.
Language server support for config dependency list updates.
Spans in config diagnostics.
Support for git urls.

crates/common/src/config.rs

crates/common/src/ingot.rs

crates/resolver/src/ingot.rs

crates/hir/src/hir_def/mod.rs

crates/common/src/ingot.rs

sbillig · 2025-08-30T02:27:48Z

Readd support for --core flag.

I think we should drop support for specifying a custom core lib, and only support a custom std lib (when we figure out what the std lib should be). Core should be limited to things that wouldn't be interesting to replace. The compiler depends on core containing a certain set of traits and impls.

micahscopes

Overall looks good to me! Only changes I'd suggest are organizational:

keeping the tree structure out of common crate since it's part of a pretty specific feature
using less generic names for the dependency graph stuff in common

micahscopes · 2025-08-31T22:28:55Z

crates/common/src/tree.rs

What's your thinking for keeping this in common vs in fe or in the resolver?

this is used in both the driver and fe crates to format trees. fe is off the table due to driver needing it and seeing as this module just deals with the printing of dependency trees I don't think it belongs in the resolver crate.

micahscopes · 2025-08-31T22:32:43Z

crates/common/src/graph.rs

The naming in here seems pretty generic, any reason not to have more specific naming, even just at the module level? So that we could have something like dependencies::Graph or dependency_info::Graph? Or were you thinking this could potentially be useful for creating lots of different kinds of graphs, not just for dependencies?

I think this makes sense. the dependency tree formatting stuff could also be moved into that module, which would maybe make things a bit cleaner.

micahscopes · 2025-08-31T22:34:41Z

crates/language-server/src/functionality/handlers.rs

Loving all these consolidations 😎

g-r-a-n-t marked this pull request as draft March 28, 2025 18:24

g-r-a-n-t marked this pull request as ready for review April 9, 2025 18:55

g-r-a-n-t force-pushed the resolution-handler branch 2 times, most recently from a7ce31a to a61d9e9 Compare April 10, 2025 03:36

g-r-a-n-t force-pushed the resolution-handler branch 5 times, most recently from fd31a02 to 06381f9 Compare April 22, 2025 15:58

g-r-a-n-t force-pushed the resolution-handler branch 3 times, most recently from ec49518 to 5430d93 Compare April 28, 2025 19:59

g-r-a-n-t force-pushed the resolution-handler branch 2 times, most recently from 685f878 to 1069810 Compare May 6, 2025 20:59

g-r-a-n-t force-pushed the resolution-handler branch 3 times, most recently from f28fd37 to d0b347d Compare May 20, 2025 16:52