create HHIs upon prototype start
commit0ee31418b52e882787983b2eecd073c3215159eb
authorLucian Wischik <ljw@fb.com>
Sat, 9 Nov 2019 00:11:43 +0000 (8 16:11 -0800)
committerFacebook Github Bot <facebook-github-bot@users.noreply.github.com>
Sat, 9 Nov 2019 00:14:00 +0000 (8 16:14 -0800)
tree3603e081db6ad376735fa784584435cebb19abac
parent1429aa52487accdbba2509e6a815d7d3bd6d7bf5
create HHIs upon prototype start

Summary:
When should hhi files be created?

* In the current hh_server, the hh_server daemon creates them each time it starts. And `hh_server check` also creates them when it starts. ServerlessIDE I think also creates them when it starts. So does hh_single_compile.
* But what do we do in the new rearchitecture?
  * I had originally sidestepped the question by having them be created by the mapreduce orchestrator (yuck).
  * Tatiana needed them in hh_decl, but also sidestepped the question by adding an argument `hh_decl --hhi <path>` where you trust that someone else has created the decls.
  * So we're in the strange situation where mapreduce orchestrator+workers use hhi files that were layed down by the orchestrator, while decl-service uses hhi files that were passed in by command-line argument! That can't be right.

I think the right answer is that hh_decl should be responsible for writing hhi files.

This way feels similar to hh_server. We now have a long-lived hh_decl process, similar to how we used to have a long-lived hh_server process. And hh_decl is responsible for fetching all decls, both decls for things under root, and decls for things under hhi. So it certainly at least needs to know where the HHI files are.

There aren't any other long-lived processes who are candidates for writing out hhi files... The only candidates are (1) serverless-ide is long-lived if you happen to use an IDE, (2) hh_fanout_service is long-lived if you happen to launch hh in incremental mode, (3) hh_decl is long-lived and is always used in all modes of hack.

So, we've concluded that hh_decl should be the one laying down hhi files.

I'm therefore exposing `hhi_root` as a member of `Decl_service_client.t`.

Next question: when should it do this? Ideally I'd like to move it over to Rust. But I can't be bothered to do that right now. Instead, I took advantage of the fact that hh_decl and the prototype have a 1:1 relationship, where hh_decl spawns prototype upon startup, and hh_decl terminates should prototype ever die. Therefore, it's pretty much equivalent whether hh_decl or prototype lay down the hhi files.

I made prototype lay down the hhi files upon startup. This is a pretty trivial change. It reports back to hh_decl where it layed them down.

(The next diff in the stack will make hh_decl read that location).

Reviewed By: 2BitSalute

Differential Revision: D18364647

fbshipit-source-id: e7d05c8bbce3706560cdef23d308423fc16f119f
hphp/hack/src/providers/decl_service_client.ml
hphp/hack/src/providers/decl_service_client.mli