Update 18/4/19 #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: What it says on the tin. The semantics is exactly the same as for the `noreturn` type (but the two types behave differently wrt type-checking). Reviewed By: andrewjkennedy Differential Revision: D14279910 fbshipit-source-id: 349c134139e8b3f02ece25069591880e007845af
…o typeing error Summary: In order to be able to fixme this type of error it cannot be a parser error Reviewed By: kmeht Differential Revision: D14790653 fbshipit-source-id: f2422ab67662d75d206ee2cf02becacdeabd02ed
Summary: It's dead. Reviewed By: yfeldblum Differential Revision: D14191959 fbshipit-source-id: 8cfb68fa8f10b1f847bf6601aec8d869cb9c008d
Summary: The HHJS transpiler emits a godawful number of closures--we'd like to profile the output code but it's difficult to do with the default name-mangling; and it seems like overkill to do our own closure conversion that names things more sensibly. This adds support for a user attribute `__ClosureName` that inserts a user-provided string into the mangled closure name. Not sure if this is a kosher thing to do or not--feedback on this approach is more than welcome. Reviewed By: oulgen Differential Revision: D13975389 fbshipit-source-id: b83da6beb570bbc94b2a723d7904daf9cfadcf8c
Summary: `emit_lval_op()` used `stash_in_local_with_prefix()` to implement list assignment. It was buggy. If RHS was a local that was used inside the list assignment on LHS, it would be used directly instead of being stashed into unnamed local and it would get overwritten in the middle of list unpacking. This bug does not seem to be present in older versions of HHVM, so perhaps it was introduced by HackC. It was also introduced by PHP5.1.0 and fixed by PHP7.0.0: https://3v4l.org/SulFW This bug was also causing behavioral difference between the typechecker and runtime, as demonstrated by the newly added test (it typechecks just fine, but fails on typecheck at runtime). This diff converts usage of unnamed local to `Scope.with_unnamed_local()` and does not copy the buggy optimization from `stash_in_local_with_prefix()`. Instead, the optimization is left to hhbbc, which properly tracks local usage and optimizes away locals only when it is safe to. Reviewed By: alexeyt Differential Revision: D14635269 fbshipit-source-id: 36b8a3860d3c26bb24eec06ecb61895da4108277
Summary: We have both `noreturn` and `nothing` in the implementation of the type checker, but the type described in the spec as the bottom type and is currently called `noreturn` really corresponds to `nothing`. Reviewed By: kmeht Differential Revision: D14799396 fbshipit-source-id: 9a5ebaa46c2ce4a2d53e5e609e0defeda33321f3
Summary: All calls have been converted to the NetworkSocket overload Reviewed By: yfeldblum Differential Revision: D13566829 fbshipit-source-id: c6a3b155ffe35534c0297eba7819413e4ce77282
Summary: When taking a slow path of method dispatch PGO, do not exit to the same opcode with PGO disabled, but emit effects of FPush and exit to the next opcode. We are likely to have all FPush inputs in registers, so it's better to just use these inputs to write an ActRec rather than spilling them onto the stack. We still need to exit into a new translation, otherwise the fast path will lose information about the exact called method. Reviewed By: alexeyt Differential Revision: D14761983 fbshipit-source-id: 802e4b9c2a50bfbb4de9c228e9f2125f1f88896a
Summary: Original commit changeset: cd3dbd7acbbd azjezz (non-FB user) brought up some interesting issues related to static methods that I think are worth having a design discussion over. Reverting for now Reviewed By: kmeht Differential Revision: D14813437 fbshipit-source-id: 582dfaaec5e1b3bedd90e01a37698dc585922eea
Summary: The previous algorithm may result in double counting, as the maximum stack depth without FPI and maximum FPI depth may not happen at the same time. Incorrect maxStackDepth count affects inlining decisions. This happens especially in the presence of FPush* opcodes that pop items from the stack, where we are guaranteed to double count the popped items. Fix this by keeping track of only one maximum that includes both components. Reviewed By: paulbiss, alexeyt Differential Revision: D14805889 fbshipit-source-id: 14eb8c40ece2d17bbc0b41c22790f5d2354ba7f2
Summary: Unnamed locals are never bound to `$GLOBALS` (see `NamedValueTable::attach`) and thus do not need to be pessimized to TGen. Makes it less likely for a PopL/PushL peephole optimization to change outcome of type inference and blow up later in DCE. Reviewed By: markw65 Differential Revision: D14815271 fbshipit-source-id: 3ea6829882429c01368608f4300f48677bef0e1f
Reviewed By: alexeyt Differential Revision: D14669668 fbshipit-source-id: 16bb4674bccf83ffd737e60d1fd9fd4a0093f77c
Summary: Destructors are run in inverse order to their creation, so there's a small window where `wrapper` is destroyed but can still be used. This was causing my ASAN builds to crash with a use-after-scope error. The fix is to ensure the pointer to `wrapper` is unset before the `wrapper` object is actually destroyed, rather than shortly after. Reviewed By: ricklavoie Differential Revision: D14815979 fbshipit-source-id: db4435be03825e3ade03a21b6b90971feb26ca1a
Summary: Explicitly reserve 3 cells worth of stack space for ActRec. This space is filled either with 3 NullUninits, or `$this` and 2 NullUninits for FPushCtor and FPushObj* opcodes. All other stack input of FPush opcodes is carried outside of this space. Makes it easier to move FPush after function arguments. Reviewed By: ricklavoie Differential Revision: D14014872 fbshipit-source-id: c36c818e705b9e2021d42ef556536120e443349a
Summary: Emit FPush* opcodes after arguments are pushed on the stack, which is right before the FCall. Reviewed By: ricklavoie Differential Revision: D14335127 fbshipit-source-id: dda928dacbff8fcd9391855abe5cda6402677390
Summary: If a function uses more than kMaxTrackedLocals (currently 512), we assume that every opcode may use all locals beyond that number. This causes us to emit (num_locals - kMaxTrackedLocals) assertions for every single opcode, potentially causing the bytecode size to be `O(N^2)` of the original code size. If such function has a try/catch block, it will emit these assertions in front of the Catch opcode, violating bytecode rules and triggering verifier. Let's not emit assertions for untracked locals. Reviewed By: ricklavoie Differential Revision: D14820350 fbshipit-source-id: 2da749d93f272764ac64a8ef87476dbb92db59af
Summary: Since we no longer emit any code between `FPush*` and `FCall`, all `try/fault` uses has their `try` block outside of a FPI region. This allows us to replace these `try/fault`s with `try/catch`es. Reviewed By: ricklavoie Differential Revision: D14657193 fbshipit-source-id: 6ee4dd02e00fce15bc8b5ea7706ebc8dbe410058
Summary: No longer used. Reviewed By: ricklavoie Differential Revision: D14669624 fbshipit-source-id: 11126834c5f40cce1108863bd97d41ac9bf10126
Summary: No longer used. Reviewed By: ricklavoie Differential Revision: D14669669 fbshipit-source-id: acf72e0524cfdf90a457f4551caf334282462155
Summary: Instead of starting exception handler with empty stack and using Catch opcode to obtain the throwable from the stack of Faults, push the throwable explicitly by the unwinder before entering exception handler. Reviewed By: ricklavoie Differential Revision: D14677951 fbshipit-source-id: 5c3d0a8a45f4c2c774da82613ccbdeff49dd1d06
Summary: Removal of fault funclets and Catch opcode trivialized usage of the stack of faults. This stack is always empty except for the duration of invocation of unwindPhp(), when it stores the fault that is being processed by the unwinder. Let's just use a variable for that and simplify the code. Reviewed By: ricklavoie Differential Revision: D14679006 fbshipit-source-id: 534bd6406312c8821d1b714cef3f4c9f386bdcd5
…s set Summary: since `$0ReifiedGenerics` contains the reified generics list that needs to be accessed while printing the backtrace Reviewed By: ricklavoie Differential Revision: D14811553 fbshipit-source-id: a0e32518765def4b83019303ff980dcdf6370147
… a lval-as-an-expression Summary: Because we don't support `async` and `inout` on the same function, we shouldn't support it as a final position. Also because &'s are slanted for removal and hack has traditionally had a firm belief they don't exist I'm going to exclude them from being counted as `lval-as-an-expression`. Reviewed By: Matt-Schellhas Differential Revision: D14789082 fbshipit-source-id: 7d23d77bd84f4ae976a59528588f0b7a05badb0c
Summary: `FunctionCallWithTypeArgumentsExpression` is a pain to work with and promotes bugs because you have to remember to apply checks to both. This diff folds it into `FunctionCallExpression` and add a `type_args` field to it. Reviewed By: oulgen Differential Revision: D14765091 fbshipit-source-id: 9ea8f4e8b5c75d46019eda2c6826549cf16940b7
Summary: Show the full path, relative to the current working directory. This is consistent with the raw error formatter. Reviewed By: DavidSnider Differential Revision: D14801496 fbshipit-source-id: bb83b01114ccdde65fd9e6080cc64a3b493199ac
Summary: During development of new_inference, it was useful to have the ability to turn off eager solving of type variables. But this is now a critical feature, and more nuanced (e.g. the use of narrowing). It seems pointless to have this control now. Reviewed By: CatherineGasnier Differential Revision: D14798101 fbshipit-source-id: 0e58cd7af6fcccd86f3397e475a93a57978c298d
Summary:
For some reason, I use to get
```
File "src/utils/dune", line 18, characters 4-20:
18 | get_build_id.gen)
^^^^^^^^^^^^^^^^
Error: get_build_id.gen does not exist as a C source. get_build_id.gen.c must be present
```
with dune 1.8.2
Somehow changing `get_build_id.gen.c` to `get_build_id_gen.c` fixes it.
Filed a bug: ocaml/dune#2033
Reviewed By: Wilfred
Differential Revision: D14804759
fbshipit-source-id: d1f9fcdeeede7919a50d0734578cad195b4d4d69
Summary: On any user message, send back the thread id. This will allow the client to filter and ignore messages that are not coming from either the REPL thread or the curren request thread. Reviewed By: alexeyt Differential Revision: D14777432 fbshipit-source-id: f741a9afb90f296d9178437afd0cb60807d66f3c
Summary: Use the debugger format from VariableSerializer, as hphpd does, to return a serialized text version of the variable in addition to the structured version used by IDE's. Reviewed By: alexeyt Differential Revision: D14785434 fbshipit-source-id: 86ffc0d9c3d4802dd6ef8037d28e15df73d0ed83
Summary: Currently, the analysis phase runs multithreaded, but then the update phase runs single threaded. Most of the work in the update phase is parallelizable (its just updating information about the current function, or class, and nobody else will be updating that data). In some cases the data was kept in a hash table of some kind, so we need some kind of locking when looking up entries, or inserting entries; but the entries themselves are only ever updated by a single thread. In some cases I used tbb, and in others I just used a lock. Reviewed By: ricklavoie, jano Differential Revision: D14815273 fbshipit-source-id: ae51ec6ff3f2805b72cc0447752b65b1ac7f0622
Summary: Begin scaffolding to enable the symbol search system to implement multiple providers with a single consistent API (index_search). This new API does not depend on any of the trie-specific features, and it can separate "local file symbols" from "global file symbols". In this current diff nothing is yet switched to use it; that will follow in the next diff. Add a test suite that can be used to test different autocomplete providers against each other. Reviewed By: 2BitSalute Differential Revision: D14900393 fbshipit-source-id: 4880d5f02f08284fa0372242b2776ff67631aba9
…arations Summary: When this flag is enabled, we will look up class members lazily from shallow declarations instead of eagerly computing folded declarations representing the entire class type. The remainder of this stack adds lazy-lookup implementations for the Typing_classes_heap API. Reviewed By: pittsw Differential Revision: D14876507 fbshipit-source-id: 42173aa82c7126bea1d2e3585d79e9b8e248dcff
Summary: While we have two implementations of class declaration, we should exercise both of them in automated tests to help ensure that they don't get out of sync. Reviewed By: pittsw Differential Revision: D14876509 fbshipit-source-id: d59546e1d9456a42411f1f304047cd37141949d3
Summary: Shallow_classes_heap is intended to replace Decl_heap.Classes (and its companion heaps, Methods, StaticMethods, Props, StaticProps, and Constructors) as the shared memory store for class declarations. This diff switches it over from a worker-local OCaml-heap cache to a true shared memory store. If we store both shallow classes and folded classes in shared memory, we cause a memory regression. Therefore, this diff throws on any attempt to cache shallow classes in shared memory when shallow_class_decl is disabled. Reviewed By: pittsw Differential Revision: D13570861 fbshipit-source-id: e53f8a9c9a94872b9ecbd7267fb825595d24a37a
Summary: While experimenting with running D13571860 over WWW, I found that sharing linearizations between workers was critical for performance--this diff reduced a 74% perf regression (from trunk) to a 24% regression. This diff adds a shared memory cache for linearizations so that completed linearizations (we cannot serialize the functional values in partially-computed linearizations) can be shared between workers. Reviewed By: pittsw Differential Revision: D13571859 fbshipit-source-id: 98782b23a74f60444b3fbff59537ae47035293d2
Summary:
When `shallow_class_decl` is disabled, we must avoid lazily looking up shallow class declarations using `Shallow_classes_heap.get`. As of {D13570861}, this function throws an exception when `shallow_class_decl` is disabled, since without a shared-memory store of shallow classes, we have no guarantee that we aren't wasting time needlessly re-parsing the class we are trying to look up.
When `shallow_class_decl` is enabled, we must avoid computing `decl_class_type`s or `Typing_defs.class_type`s, since we would like to replace all uses of them with lazy lookup. Computing and storing the legacy class types will waste time and memory.
To deal with this, we represent classes in Typing_classes_heap with a new type, `class_type_variant`:
```
type class_type_variant =
| Lazy of lazy_class_type
| Eager of class_type
```
When `shallow_class_decl` is enabled, we only ever construct the `Lazy` variant. When it is disabled, we only ever construct the `Eager` variant.
Wherever we currently use `decl_class_type` directly (for example, in `Ppl_check`), we replace those uses with `Typing_classes_heap.t`, so that when shallow class decl is enabled, we will lazily look up the information instead of relying on the eager-class-decl store being populated.
Previously, the `dc_ppl` field was not propagated to `Typing_defs.class_type` because the `Ppl_check` module used it on `decl_class_type` directly. Since we are now using `Typing_classes_heap.t` to abstract over whether `shallow_class_decl` is enabled, it's necessary to propagate this field to the typing `class_type`, and we add the field `tc_ppl` and the accessor `Typing_classes_heap.ppl`.
Reviewed By: pittsw
Differential Revision: D14876508
fbshipit-source-id: 2a3b3a0f1d0649e51da7aa83408b02a2035f7d18
…s enabled (for now) Summary: Since we expect Decl_heap.Classes to be empty when shallow decl is enabled, there is no point in attempting class-diffing during incremental typechecking. Instead, just add all dependencies (as we do when no old decl is available to diff against). Reviewed By: pittsw Differential Revision: D14876506 fbshipit-source-id: fa588bc8adf3c11787192c1e3338706e4f01d513
Summary: This is the first diff of several which implements lazy lookup in Typing_classes_heap for a bit of folded information stored in decl_class_type. The folded information will be removed from decl_class_type in a separate diff. Reviewed By: ljw1004 Differential Revision: D13571853 fbshipit-source-id: e167d62c6884e22d5dbe1c81c61d634a67f37775
Summary: This diff introduces the Decl_inheritance module, which will provide the implementation of lazy lookup for all class members. This diff implements lazy lookup for methods only; other class member kinds are covered in future diffs in this stack. This diff also introduces a companion module Typing_inheritance, used to verify overrides of methods against every previously-inherited version which was overridden. Decl_inheritance provides `all_inherited_methods` and `all_inherited_smethods` for consumption by Typing_inheritance. Currently, Typing_inheritance is used only for detection of `<<__Override>>` annotations on methods which do not override any other method, but we could choose to move more checks into it in the future. Because we now verify overrides in Typing rather than Decl, the test case integration_ml/test_failed_decl must be changed. This test case exercises behavior in the presence of Decl-phase errors, but the override error is now a Typing-phase error, so we must replace that error with some other error which is still emitted during the Decl phase. Differential Revision: D13409652 fbshipit-source-id: c7a9c8ea4c9d26a42f533a3f1866620749230a0a
Summary: Add property lookup to Decl_inheritance, the lazy class-member-lookup module added in D13409652. Reviewed By: pittsw Differential Revision: D13571858 fbshipit-source-id: d3b87c909dddc43f64cb606cadb2a142fed7ca45
Summary: Add constructor lookup to Decl_inheritance, the lazy class-member-lookup module added in D13409652. Reviewed By: arxanas Differential Revision: D13571861 fbshipit-source-id: 7908dd12a83c6157216fb9811dcf5dadb9ff10cb
…ss_decl is enabled Summary: Now that `Typing_classes_heap.lazy_class_type` provides lazy lookup of class constructors from shallow declarations, it is possible to determine whether a class has members which need initialization without using the folded `class_type`. This diff removes reads of `tc_need_init` and `tc_deferred_init_members`, bits of derived information about the class constructor, when shallow_class_decl is enabled. The module deriving the set of deferred init members, Decl_init_check, is duplicated (and slightly modified) as Typing_deferred_members, since it is now invoked per-file by Typing (via NastInitCheck) rather than done ahead of time during eager decl. Reviewed By: arxanas Differential Revision: D13571855 fbshipit-source-id: edfbcbd65b48b174f7376538a919b332e4dd3137
Summary: Adds class constant lookup to Decl_inheritance, the lazy class-member-lookup module added in D13409652. This diff also removes the now-unused class-element conversion and substitution functions from Decl_class. Const lookup is complicated somewhat by the existence of the legacy [Enum](https://our.intern.facebook.com/intern/codex/symbol/php/Enum/) class. For any class which extends Enum (even indirectly), Hack must assign all of its class constants a different type. Consider this example: ``` class MyEnum extends Enum<num> { const ONE = 1; const TWO = 2; } ``` Normally, `MyEnum::ONE` would be inferred to have type `int`, and that type would be reflected in the representation of the class const `ONE`. However, because MyEnum extends `Enum<num>`, the class const `MyEnum::ONE` is assigned the type `num` in the typechecker. Because of this, we cannot assign a type to any class constant until we have either 1) examined the entire linearization to determine that it does not contain `Enum`, or 2) encountered `Enum` in the linearization. We reuse the ancestors cache produced by Decl_ancestors to memoize this lookup. In the future, it might make sense to provide a marker interface `IEnum`, and require every class which extends the legacy `Enum` class to implement it. Then we could do this rewriting of constant types without needing to examine the entire linearization. Alternatively, maybe we could codemod legacy enums to explicitly annotate the types of their constants, and stop doing this rewriting altogether. Const lookup must also consider the implicit classname constant `C::class`, and the implicit `TypeStructure` constants generated for each type constant. Reviewed By: arxanas Differential Revision: D13571851 fbshipit-source-id: 66a9be11ca3a4d4dcecbd2ef5a3bdc7a112c98eb
Summary: If we propagate ttc_typeconst to overrides, we end up with a severe performance regression with shallow class declarations (on the order of 15%). Instead of propagating this property to overrides and doing this enforcement in a Tast_check, do the enforcement in Typing_extends, so that propagating the property to overrides is not necessary. Reviewed By: arxanas Differential Revision: D14567951 fbshipit-source-id: d64425328af21272eb0f851cabb81aa97f154705
Summary: Add type constant lookup to Decl_inheritance, the lazy class-member-lookup module added in D13409652. Differential Revision: D13571856 fbshipit-source-id: b7627b705e805d85587123cc4b50be04d800f5be
Summary: Pull Request resolved: #8481 Reviewed By: CatherineGasnier Differential Revision: D14840083 Pulled By: fredemmott fbshipit-source-id: 57a6cee3b2ba4a66c17e12d5608b2ef0676b4ef4
Summary: This diff is a prerequisite for making layout changes to existing collections. Outside of wide mode, it shouldn't have any performance affects. Most of the changes here update collections.h to return tv_lvals and propagate them through the rest of the codebase. I also modified a few of the collections-vector methods to use tv_lval internally with a new dataAt(int64_t) method which we can easily switch to a new layout. The bulk operations (map, filter, popFront, etc.) still use the data() method and make layout assumptions. Reviewed By: mofarrell Differential Revision: D14748846 fbshipit-source-id: fc6bb8563073ec19a20cd766fade7c11c46fe1ef
Summary: This diff makes almost all the code in ext_collections-vector.cpp agnostic to the layout of its backing store, PackedArray. Most of the changes are in various bulk operations (map, filter, take, etc.) that iterate over the array. Many of them now use a copySlice helper that we can optimize with layout-specific logic if needed. There are two places where I left the layout assumption in place. Both are marked with static asserts: - resizeImpl (uses memcopy to bulk-copy data from the old buffer to the new one) - removeKeyImp (uses memmove to bulk-move data; I made popFirst share this code) If we use a new layout, we can probably still do the memcopy on resizeImpl, just with a different size in bytes. For example, if we use the "8 type bytes + 8 value words" layout, an n-element vector will use `n + ((n + 7) >> 3)` bytes. Using memmove for removeKeyImpl is a lot trickier with that layout, though there are still ways to do it. Outside of the core changes, I added a few utilities like tvSwap and new Variant constructors. I think tvSwap is useful elsewhere, and I may try to make that change in another diff. The Variant constructors are a little rough, though - for instance, I wasn't able to call them with a TypedValue, and I couldn't get them to work with T&& instead. Reviewed By: mofarrell Differential Revision: D14762565 fbshipit-source-id: e288b3eece5d6733d4a30b8391c03a4720254e7e
Summary: Generating sequential numbers for variants that reflect OCaml memory representation fo those types. (Note: this ignores all push blocking failures!) Reviewed By: Wilfred Differential Revision: D14574813 fbshipit-source-id: 84ce6c594f03d8c37d69d293622cb333577d64fc
Summary: As in title - handcrafted mirrors of OCaml structs. Hopefully one day we will get an intern who can write an automatic deriver. For now - those structs haven't changed in years, so I think we can include the manual ones in initial prototype. (Note: this ignores all push blocking failures!) Reviewed By: losvald Differential Revision: D14574819 fbshipit-source-id: 85f366758f20e9a02f09b1847d7bf86507ed6c9c
Summary: I put it in `/tests/`, but it's not really a test intended to run continuously - just a small demo binary useful when developing. (Note: this ignores all push blocking failures!) Reviewed By: losvald Differential Revision: D14574827 fbshipit-source-id: 330196803c27a23f947dc9d42945412b5d8e8cf4
Summary: This diff changes `hphp_get_status` to cast the result to an array before casting to darray. This is exactly what `object_prop_array` does -- not sure if jano prefers this instead. Reviewed By: paulbiss, jano Differential Revision: D14953145 fbshipit-source-id: ceb9e439b780ac0c4827330a0ad3d0a5be72e6fe
Summary: Original commit changeset: 354036104933 Reviewed By: billf Differential Revision: D14979812 fbshipit-source-id: 1f136b333fd9e9b0bf1e4593fe5bfc9505b34c71
Summary: Type checking of `switch` is affected by whether or not the cases are exhaustive, in the absence of a default. This in turn relies on detecting that the scrutinee is an enum. If it's a type variable, we should solve it eagerly. Reviewed By: kmeht Differential Revision: D14977403 fbshipit-source-id: ec670ad4320006c71350e22e9962e08b444a13c9
Summary: Its dead. Reviewed By: binliu19 Differential Revision: D14966814 fbshipit-source-id: 5240bee1e6c5790ec7320ef74adf1261453d89e4
Summary: It's not always clear that `"loading saved state succeeded" not in logs` means that `hh_server` died, so add a message that points that out. Differential Revision: D14984984 fbshipit-source-id: 8fa725ef5fc63b502e142e326011a9b97162a660
Summary: Currently, the assembler just passes symbol refs to a set of (optional) callbacks. I want to be able to cache the result of parsing the inputs to an hphpc build, but that means caching the symbol refs too. The current callback mechanism doesn't even tell me which unit the symbol refs come from, so a better solution seems to be to cache them on the unit itself. We don't need these for regular builds, so make it optional whether they're generated, and in this diff, I don't provide the option to save them to the repo. I'll add that in the diff that enables caching. Reviewed By: paulbiss Differential Revision: D14976841 fbshipit-source-id: 0b5e0d8d7a66f820563cbf826cb6a77943d7f547
Summary: I want to be able to use a repo to cache units for `--hphp` builds. The problem at present is that when Option::WholeProgram is true, units that get created always use the global litstr table; and when RuntimeOption::RepoAuthoritative is true, units loaded from the repo assume they're getting global ids. We can't (easily) build a cache incrementally if it uses the global litstr table, but we also can't feed a mix of units to hhbbc where some use the litstr table, and some do not (and any newly parsed units will use the global litstr table). This adds a flag to each unit to say whether it was built (or should be built) using the litstr table, and changes things so that only units written by hhbbc use the global litstr table. Reviewed By: ricklavoie Differential Revision: D14919599 fbshipit-source-id: 9c33b99f43f0f86c202bebb1b4aeb62fbbefc6ad
Summary: If you specify a read-only local repo, `hhvm --hphp` will try to read units from that repo, and skip parsing it if its there. If you specify a read-write local repo, `hhvm --hphp` will additionally write any newly parsed units back to the local repo. This is a relatively slow process, so to avoid slowing down the build when the cache is relatively empty, we normally just stop writing units when parsing finishes. Finally, if you specify --target=cache, the behavior is the same, except hhvm will allow all the units to be written to the cache, and won't run hhbbc, or write an optimized repo. Reviewed By: ricklavoie Differential Revision: D14987918 fbshipit-source-id: 2be9c4be1c57aea3ca612275d1d5cbc95a864798
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.