[ty] Make Module a Salsa ingredient

[BurntSushi]

We want to write queries that depend on Module for caching. While it
seems it can be done without making Module an ingredient, it seems it
is best practice to do so.

[BurntSushi]

@MichaReiser RE #19408 (comment)

What would be the downside of leaving Module as it was and not making it an ingredient? Is it that dependency tracking in Salsa won't be as good as it would be with this change? I'm trying to figure out what would go wrong if we kept the status quo. (I'm not arguing in favor of the status quo, this is for my own edification.)

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[carljm]

I'm curious, given that File:Module is 1:1, why we need to make queries cache based on Module instead of based on its File? AFAIK we've mostly just based everything around File.

[MichaReiser]

What would be the downside of leaving Module as it was and not making it an ingredient? I

The main downside is that all_submodule_names requires the () dummy argument because its (otherwise) only argument (self) isn't a salsa ingredient. What this does behind the scene is that salsa creates an ad-hoc interned struct with two fields: dummy: () and module: self.

I'm curious, given that File:Module is 1:1, why we need to make queries cache based on Module instead of based on its File? AFAIK we've mostly just based everything around File.

I must admit, I didn't look at all_submodule_names in detail and you're right, we could restructure that function so that only the portion operating on File would be the salsa query. That would remove the need to make Module a salsa query today.

It being a salsa struct would still be beneficial if we need queries operating on namespace packages or queries using other Module fields that can't be as easily restructured as all_submodule_names.

@BurntSushi has probably more insight here on whether we want to extend all_submodule_names to namespace packages in the future or if there are other queries that need to operate at the module level

[BurntSushi]

@BurntSushi has probably more insight here on whether we want to extend all_submodule_names to namespace packages in the future or if there are other queries that need to operate at the module level

I am not 100% certain about this, but I suspect so. I'm thinking about queries for symbols exported by modules (for auto import). If I'm wrong about this and Module is unnecessarily a Salsa ingredient, what kind of downsides are we looking at? Extra memory usage? If it isn't too bad, I think I'd prefer to keep it as an ingredient for now.

I've pushed up another commit that does restructure the code to just use File as an input to a query function.

[MichaReiser]

If I'm wrong about this and Module is unnecessarily a Salsa ingredient, what kind of downsides are we looking at? Extra memory usage?

• Accessors are slightly slower as they require a db lookup and they're a bit more annoying to use
• Salsa has to track additional metadata for each tracked struct. I don't expect this to be a huge problem here as there are relatively few modules (it's not in the millions)

I am not 100% certain about this, but I suspect so. I'm thinking about queries for symbols exported by modules (for auto import).

Makes sense. The main question is if they could be over File instead of Module. But I'm fine merging this as is.