Parallel RBI generation is not deterministic because of autoload

[vinistock]

When generating RBIs, we require the bundle/application ahead of time in the main process, but that's not sufficient to load the entire code.

When we delegate generation to the Executor, the SymbolTableCompiler will autoload constants for the first time inside a forked worker. This means that the other workers will not know about the autoloaded constant, which leads to RBIs that are not deterministic.

It's possible to verify that this is the case by inspecting the $LOADED_FEATURES outside and inside of the forked workers. This prints different loaded features from the workers, which is most likely the source of the non-deterministic behavior when running in parallel.

# lib/tapioca/generators/gem.rb

def generate
  # ...

  current_features = $LOADED_FEATURES
  Executor.new(.....) do |gem|
    puts $LOADED_FEATURES - current_features
    # ...
  end
  # ...
end

[paracycle]

I have been working on triggering autoloads eagerly before starting to generate gem RBIs. I think I can get that merged this week, which should solve this as well.