1. 20 9月, 2021 1 次提交
    • A
      Wait in a loop for jemalloc threads to stop · 64834993
      Arnab De 提交于
      Summary: Currently server tests are flaky because jemalloc background threads may take some time to stop.
      
      Reviewed By: binliu19
      
      Differential Revision: D30995020
      
      fbshipit-source-id: 1f39faf26a350a0c1fd088faf7e08892211b1ff4
      64834993
  2. 19 9月, 2021 1 次提交
    • B
      Use the correct values when querying the database for type attribute arguments. · 540fbb8b
      Brett Chik 提交于
      Summary: When querying the database, currently the query has a predicate for kind_of='type' except this isn't actually an allowed value for this field.  It should instead be kind_of <> 'typeAlias'.
      
      Reviewed By: scotthovestadt
      
      Differential Revision: D31035021
      
      fbshipit-source-id: d2dc1ed6b7a82b502b25d884f9059a8cff1a4c74
      540fbb8b
  3. 18 9月, 2021 18 次提交
    • S
      Delete PersistentKeyOrder · d5350e33
      Shaunak Kishore 提交于
      Summary:
      PersistentKeyOrder was a way to mark those KeyOrder that got used to create StructLayout, so that we could clean up the rest.
      
      Now that we no longer keep a KeyOrder in StructLayout, we can delete PersistentKeyorder.
      
      Reviewed By: colavitam
      
      Differential Revision: D30996887
      
      fbshipit-source-id: b542096355f70bd215c9c6afdb30af2f5c23132b
      d5350e33
    • S
      Use FieldVector to construct StructLayout · 362584e9
      Shaunak Kishore 提交于
      Summary: As arnabde03 originally noted, this diff changes how we construct StructLayout, but not in any way that should cause a logical or performance difference.
      
      Reviewed By: colavitam
      
      Differential Revision: D28295056
      
      fbshipit-source-id: e60202c0632aca7ad679cf650b4aa04c2a5bf08e
      362584e9
    • O
      Optimize VerifyParam/RetTypeTS on type aliases · f9f9d1d4
      Oguz Ulgen 提交于
      Summary: When the parameter or return type is a type alias and it is used with a reified generics, we do not need to resolve the type structure since type aliases can never be reified.
      
      Differential Revision: D31028861
      
      fbshipit-source-id: c58328a2ef5d0a67caee26b4ac3a9557912c01e5
      f9f9d1d4
    • B
      derive checksum from naming table · 6caf1409
      Bob Ren 提交于
      Summary: For the time being we don't have checksums in saved states. As a temporary workaround add the ability to derive the checksum from the naming table.
      
      Differential Revision: D30967637
      
      fbshipit-source-id: 4ac34d988d08c9af6f08f7ce46206f756cf1cf0c
      6caf1409
    • V
      Require as constraint on context aliases · 715e3484
      Vassil Mladenov 提交于
      Summary: Fixes regression from {D30287148 (https://github.com/facebook/hhvm/commit/6b3d43c2f3509c4eae8413b1bf720b5c732a28ba)}. The older parsing mandated `as` for context aliases structurally, by using `newtype X as [` to distinguish context aliases and opaque type aliases. This diff adds a lowerer check.
      
      Reviewed By: jamesjwu
      
      Differential Revision: D31028719
      
      fbshipit-source-id: c5ff9ec23c95ebb6a841dbb39a03a64bf2a7bcfc
      715e3484
    • W
      Add HHVM runtime tests for XHP with expression trees · 52582010
      Wilfred Hughes 提交于
      Differential Revision: D30530851
      
      fbshipit-source-id: 862d630dfbb06b9624d876157619f6471e924451
      52582010
    • L
      Needn't use ifiles for 64bit / shmem · ca7addae
      Lucian Wischik 提交于
      Summary:
      We now have two ways to turn a set of dephashes into a set of filenames:
      * use the reverse naming table, so long as (1) the dephashes are 64bit, i.e. the same hashes that naming-sqlite uses, (2) our naming delta is indexable by dephash, which SharedMem is earlier in the stack but LocalMem used by HackIDE isn't.
      * use Typing_deps.Files.ifiles, renamed as Naming_provider.ByHash.ifiles, which is a SECOND reverse naming table that's updated at the same time as the regular reverse naming table, and is stored in master ocaml memory rather than shmem+sqlite.
      
      This diff changes the implementation of Naming_provider.ByHash.get_files: it continues to use Typing_deps.Files.ifiles as always, but also if the conditions are met for using the reverse naming table then it does that also and verifies that the two techniques give identical results.
      
      I've written this diff just as a temporary place along in the diffstack. I don't intend to verify in production.
      
      Differential Revision: D30470723
      
      fbshipit-source-id: 9e01c99098fb1e95b2803bd832dd3836fb0f7bcd
      ca7addae
    • L
      Naming_heap.get_filenames_by_hash · 8dc82a5a
      Lucian Wischik 提交于
      Summary: This is part of my mission to replace Typing_deps.Files.get_files with the naming heap. I need to look up a DepSet.t and retrieve the associated filenames. That functionality is already present in Typing_deps.Files.ifiles. This diff adds the exact same functionality, but powered instead by the reverse naming table.
      
      Differential Revision: D30438305
      
      fbshipit-source-id: 7cc8626b1ff863e77b7500d2dd3b3c536ddbf6f1
      8dc82a5a
    • L
      clean up interface of Naming_heap.mli · e0798e7b
      Lucian Wischik 提交于
      Summary:
      I saw that Naming_heap.mli has a load of functions that shouldn't be public. This diff cleans up the public signature.
      
      I also made it so Naming_heap.{Types,Funs,Consts} are all identical:
      * Previously, Types had extra (unused) functions relating to fetching the kind of a name, so I removed them
      * Consts lacked functions relating to canonical names since they're not used. I added them for uniformity. Also, our naming-sqlite stores canonical information for consts too, also for uniformity.
      
      REVIEW GUIDANCE: read the .mli file first
      
      Differential Revision: D30938536
      
      fbshipit-source-id: f47b045a2fe896cb0726a2e4a1c5e6f05eb74451
      e0798e7b
    • L
      Naming_provider.ByHash 3/3 (remaining uses of new API) · 256fbe8c
      Lucian Wischik 提交于
      Summary:
      Earlier in the stack I'd moved Typing_deps.Files into Naming_provider.ByHash, with two APIs:
      ```
      get_files_TRANSITIONAL : DepSet.t -> Relative_path.Set.t
      get_files : Provider_context.t -> DepSet.t -> Relative_path.Set.t
      ```
      The previous diff in the stack migrated some of the clients from get_files_TRANSITIONAL to the new get_files, by threading through Provider_context.t in a few easy places.
      
      This diff migrates the remaining clients by threading through Provider_context.t in the remaining places, and deletes the old api `get_files_TRANSITIONAL`
      
      The implementation of `get_files` hasn't actually changed yet, and doesn't yet use Provider_context.t. I'll switch to that in the next diff.
      
      Differential Revision: D30470667
      
      fbshipit-source-id: 902aac9c02c0c917489ff3246e8166b9f5545b45
      256fbe8c
    • L
      Naming_provider.ByHash 2/3 (simple uses of new API) · aeb253af
      Lucian Wischik 提交于
      Summary:
      The previous diff moved Typing_deps.Files into Naming_provider.ByHash. It offered two APIs:
      ```
      get_files_TRANSITIONAL -- the old API
      get_files -- the new API for doing the same thing, but takes a Provider_context.t
      ```
      This diff migrates the easy places that used the old API, to taking the new API. It basically just threads Provider_context.t into a few more places.
      
      We don't actually use Provider_context.t yet, but once we switch over to a new backend implementation (i.e. use of reverse-naming-table rather than Typing_deps.Files.ifiles) then we will start using it.
      
      Differential Revision: D30470645
      
      fbshipit-source-id: 4c8806b768ed9a3a408649cae0e58ddd47a8f6b6
      aeb253af
    • L
      Naming_provider.ByHash 1/3 (move from Typing_deps.Files) · e0939817
      Lucian Wischik 提交于
      Summary:
      This is part of my mission to using reverse-naming-table instead of Typing_deps.Files.ifiles.
      
      This diff solely moves Typing_deps.Files into Naming_provider.ByHash. I moved it into Naming_provider because this role -- of looking up names/hashes and finding filename -- is something that properly belongs in the naming table. Also because I'll need to use Provider_context.t to determine whether the reverse-naming-table will do (i.e. if we're using sharedmem rather than localmem, and using 64bit rather than 32bit, and what is the pathname to the naming-sqlite file); Naming_provider module happily deals with ctx, but ctx shouldn't be pushed down into Typing_deps.
      
      Here's the new signature:
      ```
      (** In addition to the main reverse naming table, there is a second reverse naming table
      that does basically the same thing except you look up by hash. *)
      module ByHash : sig
        val update_file : Provider_context.t -> ...
        val get_files : Provider_context.t -> Typing_deps.DepSet.t -> Relative_path.Set.t
        val get_files_TRANSITIONAL : Typing_deps.DepSet.t -> Relative_path.Set.t
      end
      ```
      
      The old API in Typing_deps.Files.get_files didn't take a Provider_context.t. I wish to migrate to a new API which does take Provider_context.t. This diff merely provides two different APIs (`get_files_TRANSITIONAL` and the intended replacement `get_files`). Future diffs will (1) thread ctx into the callers so they can switch to the new API, (2) change the implementation of the new API, so that it starts using ctx.
      
      Differential Revision: D30465776
      
      fbshipit-source-id: 58a06090c5039e338ab39a332879136b900fcc62
      e0939817
    • L
      name heap keyed by hash · feba7bf2
      Lucian Wischik 提交于
      Summary:
      I want the naming table to be used as the dephash->filename map, rather than Typing_deps.Files.ifiles. This will require two things:
      1. The reverse naming table in naming-sqlite must support dephash->filename lookups. (This already landed)
      2. The in-memory naming heap must support dephash->filename lookups.
      
      Currently the in-memory naming heap uses SymbolName->FileName lookups. This diff therefore changes it to be DepHash->FileName.
      
      There's an irritation. Much of sharedmem depends upon keys being strings. It uses this to prefix the key with the heapname "Naming_funs_<key>", and also uses it to suffix the key with "_old" for the heaps that use oldification. (only the decl heap uses oldification).
      
      **Option1**. I could change sharedmem to support both string keys and 64bit-int-hash keys. For string keys it would allow oldification and would use its internal md5 hashing. For hash keys, it would trust the caller to have made the globally unique in some way, since it couldn't use the prefix.
      
      **Option2**. I could turn a dephash into a string "0xBA2384CF1", and use the existing sharedmem string key library. This means that each key will be hashed once into a dephash, and then a second time by sharedmem/md5 into a sharedmem key.
      
      With this diff I've opted for Option2. I expect it to be just slightly more costly, but we'll see that in the performance analysis. I expect the slightly increased cost to be greatly overshadowed by the lower cost associated with not needing Typing_deps.Files.ifiles.
      
      Differential Revision: D29893531
      
      fbshipit-source-id: da7bd82158700f5c1d7d285a17754e58735e834c
      feba7bf2
    • L
      deps_of_file_info returns DepSet.t not list · 8b06e461
      Lucian Wischik 提交于
      Summary:
      `deps_of_file_info` (prior to this diff) returns a ***list*** of dephashes. If for instance a user was editing a file and they copy+pasted a class definition so it appeared twice, they'd have "class C {}  class C {}" and `deps_of_file_info` would return the exact same dephash twice.
      
      Nothing's wrong with this. All the places where we use the result of `deps_of_file_info`, we first convert it into a DepSet.t, which removes duplicates.
      
      *Almost all*. I had recently written D30783120 (https://github.com/facebook/hhvm/commit/ba072a1061ad5c6587155f18f63ab8a37153de85) which changes `Typing_deps.Files.update_file` to remove old dephashes for a file from `ifiles`, before it adds new deps_of_file_info in. I got telemetry from users about failures, i.e. about trying to remove old dephashes from ifiles but the old dephashes didn't exist.
      
      Here's an example log:
      ```
      [2021-09-14 16:04:51.246] [master] Check kind: will bring hh_server to consistency with code changes, by checking whatever fanout is needed ('Full_check')
      [2021-09-14 16:04:51.247] [master] Also reparsing these files with failed naming: GraphTest.php
      [2021-09-14 16:04:51.247] [master] Processing changes to 1 file: GraphTest.php
      [2021-09-14 16:04:51.247] [master] Processing deferred type decl for 0 file(s), deferred typechecking for 0 file(s)
      [2021-09-14 16:04:51.247] [master] Begin Parsing 1 files
      [2021-09-14 16:04:51.251] [master] [9k, 3+1ms] GraphTest.php - classes: \GraphTest 0,0
      [2021-09-14 16:04:51.251] [master] Parsing 1 files: 0.004691
      [2021-09-14 16:04:51.251] [master] Heap size: 152459448
      [2021-09-14 16:04:51.251] [master] Begin updating naming tables
      [2021-09-14 16:04:51.251] [master] INVARIANT_VIOLATION_BUG [remove_absent_dep] file=GraphTest.php
      [2021-09-14 16:04:51.254] [master] UPDATING_DEPS_END (dephash->filename): 0.002886
      ```
      
      All the INVARIANT_VIOLATION_BUG [remove_absent_dep] I examined from telemetry had the exact same sequence -- they did a check (either full or lazy), they said "Also reparsing these files with failed naming", and then they got the remove_absent_dep bug.
      
      I inspected the code, and formed the hypothesis that the failure was due to a name appearing twice in a file. I tried it out in the IDE and was indeed able to generate this INVARIANT_VIOLATION_BUG.
      
      Differential Revision: D30951618
      
      fbshipit-source-id: dd086b549048b9b3eec5ac247137a10106fbb1a8
      8b06e461
    • J
      Enable readonly analysis for typechecker · d12e94f7
      James Wu 提交于
      Summary: This diff fully turns on rust-side readonly analysis in the typechecker.
      
      Reviewed By: oulgen
      
      Differential Revision: D30962180
      
      fbshipit-source-id: a962e599d924ba015784d700abeec87dbf0eb570
      d12e94f7
    • J
      Further improve perf and error messaging · 3b688caf
      James Wu 提交于
      Summary:
      This diff looks big, but is actually quite simple: we move all of the methods out of the visitor and into regular functions, now that we don't need the typechecker's readonly check to keep track of any state.
      
      This allows us to improve our error messaging by using parts of the function when there isn't readonly present, i.e. during complex property assignments. Instead of giving a bad error like "this prop is readonly"(which means nothing to a user not familiar with readonly), it can do a minimum amount of readonly analysis necessary to handle assignment.
      
      Reviewed By: oulgen
      
      Differential Revision: D30961623
      
      fbshipit-source-id: 2fd19b311c9e0036a0653e4788b5ec658333cc42
      3b688caf
    • J
      Support pipe expressions in readonly analysis · 2e53b9d1
      James Wu 提交于
      Summary: Support pipe expressions correctly by setting the dollardollar variable to the correct readonlyness
      
      Reviewed By: oulgen
      
      Differential Revision: D30943959
      
      fbshipit-source-id: 2c48d1951e95282f5c1b476aa860d6ac2b3aa970
      2e53b9d1
    • J
      Allow multiple filenames in --in-place mode · f19ef480
      Jake Bailey (Hacklang) 提交于
      Summary:
      Allow multiple filenames and format all of them in place.
      
      hackfmt picks up .hhconfig from the root directory of the first file given. I didn't bother to re-traverse up to the root for each file in the list here; if filenames in multiple repositories are given, then we'll apply the config from the first repo to all files in the list.
      
      This is arguably not the right behavior, but I'm not sure when it would ever happen to begin with, re-traversing to find .hhconfig and rebuild `Format_env`s would introduce a little perf overhead, and it's more work than I care to do right now.
      
      Reviewed By: DavidSnider
      
      Differential Revision: D30970848
      
      fbshipit-source-id: 4582bfa3d6c392a4a3dc5149a0634619050f10b8
      f19ef480
  4. 17 9月, 2021 20 次提交
    • F
      Run cargo_vendor.sh · 14b130ee
      Fred Emmott 提交于
      Summary: Also poked the script a bit, fwdproxy seems to have got pickier.
      
      Differential Revision: D31020060
      
      fbshipit-source-id: 49ef421f1985ddb68f57a867a4ed5548220f17cd
      14b130ee
    • V
      replace runtime representation with hhvm opaque type · 32539385
      Vincent Siles 提交于
      Summary:
      Replace the 'string' runtime representation with an opaque expression to
      prevent devs to use labels as string implicitely.
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30726883
      
      fbshipit-source-id: f56a79c088e25706523388eb495f895311341ac5
      32539385
    • C
      Daily `common/rust/cargo_from_buck/bin/autocargo` · 524d4708
      CodemodService Bot 提交于
      Reviewed By: krallin
      
      Differential Revision: D31014862
      
      fbshipit-source-id: 5176019061ab7c59dfd0f6e060c984f8b91f5533
      524d4708
    • A
      is_disposable via get_ancestor · 22e82c87
      Andrew Kennedy 提交于
      Summary:
      We have a special case in decls to store whether or not a class implements `IDisposable` or `IAsyncDisposable`, directly, or indirectly (via `require implements`). It's simpler (and as efficient) just to use existing logic (e.g. `has_ancestor`) combined with chasing `requires` types.
      
      Note that the semantics of `requires_ancestor` differs between legacy and shallow decls.
      
      In future we might consider consolidating the various `has_ancestor` functions.
      
      Reviewed By: vsiles
      
      Differential Revision: D30838752
      
      fbshipit-source-id: 2cf46e0633690e93e9c4c898f986a1d6dcd54cd6
      22e82c87
    • B
      move to position sensitive hashes in naming table · 21050e25
      Bob Ren 提交于
      Summary: As discussed in https://fb.quip.com/AGttAA62NBop, we can't depend on position insensitive hashes when calculating the change action because we still have ~48 callsites that rely on decls having positions. One day we'll fix up these callsites, but for now let's move to position sensitive hashes.
      
      Differential Revision: D30966233
      
      fbshipit-source-id: b3f8a4be355c1f61e835783a66cd9086b905fad8
      21050e25
    • D
      Update to Rust 1.55.0 · 4de4b333
      David Tolnay 提交于
      Summary: Release notes: https://blog.rust-lang.org/2021/09/09/Rust-1.55.0.html
      
      Reviewed By: jsgf
      
      Differential Revision: D30859665
      
      fbshipit-source-id: 89db9befd805babe3405522842864500550d5c8c
      4de4b333
    • M
      Time hhas bytecode generation of www · 87382bbb
      Millie Chen 提交于
      Summary: Add option `--compile-hhas` to `hhbc_www_perf:run` to measure perf for hhas generation rather than text
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30977492
      
      fbshipit-source-id: bd37d07d7c02dff558a9772e28a8be9abdf22b78
      87382bbb
    • M
      hackc_hhas_to_string_cpp_ffi · 5b203134
      Millie Chen 提交于
      Summary:
      1. Previously we introduced `compile_hhas_from_text` that takes in a source file and returns an `HhasProgram` pointer.
      2. This diff adds a function `print_hhas_to_string` that takes this pointer and produces the pretty printed bytecode. The main purpose of this function is bytecode comparison testing.
      
      Add flag `--compile-and-print-hhas` to `hh_single_compile_cpp`. When used, it invokes 1 then 2 to output the pretty printed bytecode. Note that with 1 & 2 combined, this acts the same way as the existing `compile_from_text` today (string -> string), but eventually we want 1 to replace `compile_from_text`, and the flag purely for printing/testing.
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30917476
      
      fbshipit-source-id: 2f8232c5e2125d55dac0103b921954c89afdc47f
      5b203134
    • V
      Add another test case for short context aliases · e001ec8c
      Vassil Mladenov 提交于
      Reviewed By: hgoldstein
      
      Differential Revision: D31007798
      
      fbshipit-source-id: e47a6751f9e77c959a0ceb84b24d11e019838d7c
      e001ec8c
    • J
      Use simplified stack_limit interface in rust_decl_ffi and aast_parser_ffi · 16204b7a
      Jake Bailey (Hacklang) 提交于
      Summary:
      Unlike the previous diff, this is a behavioral change: these FFIs use more constrained values than compile_ffi did. I used those compile_ffi values in the simplified interface, so this diff changes these modules to use the larger settings.
      
      I don't see a reason why it should be harmful to use the larger values, though. We currently don't hit the max stack limit (else we'd panic), and using a larger stack slack will just use a bit more memory when the elastic stack mechanism kicks in (which happens very infrequently; for just a few files in WWW).
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30980557
      
      fbshipit-source-id: 525042d00688c5ea475f94b29fdb3d4d434fe15d
      16204b7a
    • J
      Add simplified interface to stack_limit library · 65b3a6d5
      Jake Bailey (Hacklang) 提交于
      Summary:
      It looks like several callers are using identical configuration here, and almost no callers are using the `nonmain_stack_size` passed into the job closure. We could provide a simpler interface by encoding that configuration as a "reasonable default".
      
      What these defaults ought to be is up for debate. Here I've just copied the values used in compile_ffi (since they seem to be the most generous values we use).
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30980556
      
      fbshipit-source-id: 3562084e0e8dcd33f51429cca8b92aae3be57079
      65b3a6d5
    • K
      Access vmMInstrState directly · bb61d2f1
      Katy Voor 提交于
      Summary: We should be accessing the MInstrState field roProp directly instead of passing around its address.
      
      Reviewed By: ricklavoie
      
      Differential Revision: D30975782
      
      fbshipit-source-id: 21386f948c7ad806ff86503cdbf1c2fcd99b86ee
      bb61d2f1
    • K
      Add types to some DOM methods · 526d414c
      Kevin Viratyosin 提交于
      Summary:
      As described [here](https://fb.workplace.com/groups/hacklang.eng/posts/6688137947901430), better typing for these methods improves Hack's type coverage of use of iterators.
      
      Checked against HHVM implementation; also made `DOMNodeList` implement `IteratorAggregate` which currently implements `Traversable`.
      
      `DOMXPath::query` also returns an iterator, but it also may return false so it's not usefully typeable :( -- possibly for this one I can identify callsites that would throw on false anyway (e.g. immediately treated like an object) and wrap them in a function that marks the type.
      
      Reviewed By: rodmk
      
      Differential Revision: D30968424
      
      fbshipit-source-id: 30131bd11b35def5eb5f7b5501ac8c212b354598
      526d414c
    • J
      Remove stderr warnings for elastic stack retries · 2ba22c0c
      Jake Bailey (Hacklang) 提交于
      Summary: I'm not sure that we're getting any value from these warning messages. They are printed each time the elastic stack library hits the stack limit and performs a retry. This mechanism seems to have been working fine in production for a couple years now. If no one is getting value from these messages, I suggest that we remove them (people have asked me why hackfmt occasionally prints them, and wonder if something has gone wrong).
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30980555
      
      fbshipit-source-id: e5a424169782c8e30f5629e55637a1e5c734c298
      2ba22c0c
    • J
      Remove make_retryable in stack_limit API · 65999e22
      Jake Bailey (Hacklang) 提交于
      Summary:
      When the job closure was required to be Send, this API (where `with_elastic_stack` accepts a job-builder closure named `make_retryable`) was convenient: it allowed the caller to close over `!Send` values (particularly, references to `!Sync` values) in order to clone them for each run of the job closure ([example](https://www.internalfb.com/code/fbsource/[7a5c7375d33f7d16a22364ef78a06a080397257e]/fbcode/hphp/hack/src/parser/rust_parser_ffi.rs?lines=52-53)).
      
      But now that the job closure need not be Send, we can just capture those values by reference (and clone them within the job closure if needed). This diff simplifies the API by removing the job-builder closure.
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30969162
      
      fbshipit-source-id: 7e6e2864326de4dce1afdcdd36fa563219954ca8
      65999e22
    • J
      Remove Send requirement in stack_limit library · a499c395
      Jake Bailey (Hacklang) 提交于
      Summary:
      While writing the safety comment in unsafe_utils in the previous diff, I started to wonder whether it was necessary for stack_limit to require job closures to be Send at all. Since the main thread blocks while the job runs, concurrent access won't happen. I think that means that it's safe to close over Send values (and we often do in practice anyway, using `unsafe`).
      
      Instead of encoding the assumption that this pattern is safe in `unsafe` assertions at every use of stack_limit, encode the assumption within the library itself, by removing the `Send` requirement.
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30969163
      
      fbshipit-source-id: 5fa5e58ba9ab5882a8ece27f7d29ecdb773bdb6a
      a499c395
    • J
      Remove UnwindSafe requirement in stack_limit library · a869dd2d
      Jake Bailey (Hacklang) 提交于
      Summary:
      The `UnwindSafe` requirement is propagated from `std::thread::spawn`, which imposes it to help the user ensure panic safety. That is to say, it prevents the closure from closing over values which are not `UnwindSafe` (meaning that a panic may be raised while the value is in an inconsistent state which violates logical invariants).
      
      It is not necessary for memory safety or to avoid UB. From [the docs](https://doc.rust-lang.org/stable/std/panic/trait.UnwindSafe.html):
      
      > Note, however, that this is not an unsafe trait, so there is not a succinct contract that this trait is providing. Instead it is intended as more of a “speed bump” to alert users of catch_unwind that broken invariants may be witnessed and may need to be accounted for.
      
      In practice, when using the elastic stack library, we are not gaining value from this speed bump. We are just asserting that all closed-over values are panic safe (whether they really are or not). `crossbeam::thread::Scope::spawn` doesn't impose this requirement; with this diff, I'm suggesting that in stack_limit, we shouldn't either.
      
      Reviewed By: shayne-fletcher
      
      Differential Revision: D30969164
      
      fbshipit-source-id: 83272476e19b732cda4a911686a815d495a7400d
      a869dd2d
    • C
      add rollout flag deferements_light · 50a2f34a
      Catherine Gasnier 提交于
      Summary: This will be used in D30960947
      
      Differential Revision: D30991129
      
      fbshipit-source-id: 9da8b42d68ccd3494b9c4dedac482a247d02604c
      50a2f34a
    • W
      Fix typo in ET syntax error message · 0f128e12
      Wilfred Hughes 提交于
      Differential Revision: D30981964
      
      fbshipit-source-id: 64d981651e98b6f87c47f6a0f6345273ab54d690
      0f128e12
    • H
      Remove HH\sequence · fac807a6
      Hunter Goldstein 提交于
      Summary: According to D15701910 (https://github.com/facebook/hhvm/commit/ec2d9f686d88b5a63a07beb32f16e75ac0ea59db) this was added for HHJS, which is dead, so let's remove this.
      
      Reviewed By: ricklavoie
      
      Differential Revision: D30940859
      
      fbshipit-source-id: a1cca073d0e51a9cd74f8946d261ddc1e8479dd0
      fac807a6