Iterate over requested_constants in DSL helpers

[KaanOzkan]

Motivation

Speedup gather_constants performance when a constant is supplied by not iterating over the ObjectSpace. This PR shouldn't change the functionality because we intersect the constants received from the ObjectSpace iteration with the requested ones

tapioca/lib/tapioca/dsl/pipeline.rb

Line 156 in df6e272

constants &= requested_constants

Running tapioca dsl Constant before and after in the monolith:

Implementation

Tests

Most of the tests in the dsl_spec supply arguments to tapioca dsl command.

[KaanOzkan]

Open to suggestions on avoiding the class variable. We want this to be set on the subclasses of Compiler which end up calling the helper methods, descendants_of or all_classes.

[amomchilov]

This sketches me out a little, but there's a really really nice benefit to this approach: all the existing DSL Compilers will mostly just work, without needing to be updated.

What if we loosened that constraint: could we make a better API if we were willing to change the compilers?

e.g. what if the main module selection was done by something like:

sig { abstract.params(candidates: T::Enumerable[Module]).returns(T::Enumerable[Module]) }
def select_constants_to_decorate(candidates)

This would replace gather_constants. By default, we would call it with select_constants_to_decorate(all_modules) (which would work similar to how gather_constants works in practice today), otherwise we could do select_constants_to_decorate(requested_constants).

[KaanOzkan]

Hmm, I personally don't think it's worth it just for avoiding class variables because it's a public API. I'd be happy to change default compilers inside tapioca but external ones worry me. We'd have to deprecate old usages and make everyone change their compilers eventually. Or we could have logic for both but the performance benefit would be disabled for old API which also adds maintenance complexity for us.

[amomchilov]

Here's my $0.02!

[amomchilov]

This sketches me out a little, but there's a really really nice benefit to this approach: all the existing DSL Compilers will mostly just work, without needing to be updated.

What if we loosened that constraint: could we make a better API if we were willing to change the compilers?

e.g. what if the main module selection was done by something like:

sig { abstract.params(candidates: T::Enumerable[Module]).returns(T::Enumerable[Module]) }
def select_constants_to_decorate(candidates)

This would replace gather_constants. By default, we would call it with select_constants_to_decorate(all_modules) (which would work similar to how gather_constants works in practice today), otherwise we could do select_constants_to_decorate(requested_constants).

[amomchilov]

/shipit

[KaanOzkan]

Discussion: #1989 (comment)