Tags: divinity76/hhvm

Fold VPtr for addqrm

Summary: Fold Vptr for addqrm (AddBase) for next diff that uses offset-based values

Reviewed By: ricklavoie

Differential Revision: D32577107

fbshipit-source-id: 7b72417743d3beff7315bfede720d583c34a07cd

Add support for lazy loading of file contents

Summary:
If the file system provides a way to obtain a file's SHA1 without
actually reading it, we can potentially avoid reading the file at
all. We can obtain the file's SHA1, then get a hit with the unit
emitter cache hook. At this point we have everything we need and don't
need to read the file.

Instead of passing the file's contents around, instead use a
LazyUnitContentsLoader. This represents a file's contents, but it
attempts to only load the file's contents only when actually
needed. If the file system does not provide a way to obtain a SHA1, it
will load as eagerly (as normal). Otherwise it will merely obtain the
hash, and wait until the contents are actually requested.

One potential issue here: Since we obtain the file's hash first, then
potentially read the contents later, it's possible for the contents to
change after the hash read. So, when (and if) we read the file's
contents, we calculate the hash from it and check to make sure it
matches the hash we read early. If they disagree, we need to bail. The
caller is generally expected to then retry the operation. In theory
(though it should be extremely rare), this can live-lock. So, if we
detect such inconsistencies a certain number of times, we load the
file's contents eagerly. This shouldn't ever happen.

We support this lazy loading for both sandbox mode and prod builds.

Reviewed By: jano

Differential Revision: D32525102

fbshipit-source-id: e7422f335ace98e613378d32c99bb117d87f0683

third-party/rust: Update anyhow from 1.0.44 to 1.0.47

Summary:
This release helps catch places that the `anyhow!` or `bail!` macros are invoked with a missing fmt argument, such as:

```
-     anyhow!("unsupported redirect operation {:?}")
+     anyhow!("unsupported redirect operation {:?}", op)
```

All instances of this in fbcode were fixed in D32266567.

Reviewed By: wqfish

Differential Revision: D32564287

fbshipit-source-id: e9cf5a1376e6c83343de3f3c6ba2925d88334a30

update version.h

Reviewed By: fredemmott, Atry

Differential Revision: D32427663

fbshipit-source-id: 5a0a28d0608092a70ffaf6f7d13ade327bd790d2

Disable watchman in simple_repo:naming_table generation

Summary:
The simple_repo:naming_table target builds a Hack naming table from the simple_repo directory. Since Watchman seems to ignore files in buck-out directories, the target goes out of its way to read the simple_repo directory from fbcode rather than the symlinks to it in buck-out. This isn't supported in buck2.

Instead of looking for the source files in fbcode, disable watchman in the naming table builder. This lets us just use `buck_genrule` for the target rather than a custom rule and shell script.

Reviewed By: zhyty

Differential Revision: D32516092

fbshipit-source-id: 071d707762e26dbda44cd67dbd29467ec1fc9e8a

Releasing 4.136.0

shuffle - make controlled

Summary: Randomness is captured under the controlled context.

Reviewed By: rodmk

Differential Revision: D32475080

fbshipit-source-id: 4b2479d42024c9eda4bb431f7f6457d111a6e408

Ban private final methods on classes

Summary:
`final private` methods don't make sense. `final` bans overriding that method, but `private` stops child classes seeing the method.

This leads to a typehole from code of the form:

```
class MyParent {
  private final function foo(): void {}
}
class MyChild extends MyParent {
  private function foo(): void {}
}
```

HHVM rejects this, because `MyChild` is overriding a final method. hh allowed this, because `MyParent::foo` is private to `MyParent` and shouldn't affect `MyChild`.

Ban methods on classes from being both private and final.

This is a backwards compatibility break, as it bans `MyParent` even if there are no child classes. This should be an easy fix though: remove `final` from any `private` methods.

Note that this still allows `final private` methods on traits. This prevent accidental clobbering of trait methods from the using class. We might want to revisit this in future, as the same type hole exists there (see updated typehole test).

Ignore linking failure due to D32058157 breaking LTO builds.

Reviewed By: jamesjwu

Differential Revision: D28342765

fbshipit-source-id: 53adaa8a0d8a291ca6fd4c62e1f203848201a547

always warn when iterating naming-sqlite

Summary:
We shouldn't be iterating over every row in naming-sqlite.

I'd already written an NAMING_COSTLY_ITER for whenever we did that iteration, but I suppressed it for the one known case - namely, saved-state-init to populate Typing_deps.Files.ifiles.

More specifically, ServerLazyInit calls `ServerInitCommon.update_files ~warn_on_naming_costly_iter:false`, which has
```
    if Naming_provider.ByHash.need_update_files ctx then
      Naming_table.iter
        ?warn_on_naming_costly_iter
        naming_table
```
This is the only place in the codebase which can pass `false` into Naming_sqlite.iter. It can only happen if `Naming_provider.ByHash.need_update_files` returns true. Its code only ever returns true if it has to use its own ifiles, in which case it also logs `INVARIANT_VIOLATION_BUG [desc=dephash_lookup_...]`.

But we know from telemetry that nothing is producing that INVARIANT_VIOLATION_BUG/dephash_lookup any longer. Therefore, nothing is passing `~warn_on_naming_costly_iter:false` into Naming_sqlite.iter.

So, I'm going to remove the suppression.

Differential Revision: D30966608

fbshipit-source-id: e14cb200c92650fa227cec2632e7489390f1949d

Increase prof-data file max StringData size

Summary:
Now that we're encoding argument types into the prof-data file, it's
possible to exceed the 2 MB string limit. This is most apparent with
some test cases, which produce giant strings because of const-propping
in the JIT or HHBBC. If they get passed as an argument, they might be
encoded in the prof-data file.

This has always been an issue, as there's nothing preventing us from
having StringData* which are larger than 2 MB. We really should be
setting the limit at StringData::MaxSize instead. "CPP" strings can
continue to have the lower limit.

Reviewed By: oulgen

Differential Revision: D32411999

fbshipit-source-id: c6a9a5e940d09d3c178d67b016152b0b6b91c564