Tags from hhvm

Nightly v2022.05.11 for Debian and Ubuntu

2022-05-12T05:48:27Z

nix-bug-report

2022-05-04T00:18:45Z

nightly-2021.11.15: always warn when iterating naming-sqlite

2021-11-14T15:23:16Z

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

nightly-2021.11.14: Increase prof-data file max StringData size

2021-11-13T19:11:54Z

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

nightly-2021.11.13: Update get_declared_traits_basic_001.php.expectf

2021-11-13T00:10:48Z

Update get_declared_traits_basic_001.php.expectf

Summary: D32103091 (facebook@da5a7af) added an entry to the expected list, but didn't update the vec size.

Reviewed By: fredemmott

Differential Revision: D32406482

fbshipit-source-id: c8b7686d909123466fb14a98ad2ce555c7cd4562

nightly-2021.11.12: Add truncate to writable files (#8930)

2021-11-12T01:43:24Z

Add truncate to writable files (facebook#8930)

Summary:
Fixes hhvm/hsl-experimental#165

I had great difficulty reading the manpage for ftruncate. I believe there are no errno errors that we need to wrap for the caller. But because I am very inexperienced with this, I have included my reasoning below.
[manpage used](https://www.man7.org/linux/man-pages/man3/ftruncate.3p.html)

_EINTR A signal was caught during execution._
From src/os/README.md
```
### Performance

- constructing an exception requires constructing the backtrace; it should be
avoided for 'expected' cases. For example, if it is safe to, calls are
retried on EINTR 5 times.
- only do this if it is transparent - i.e. the user can't easily tell if
the call was retried or was just slow.
```
Would this be a candidate for automatic retry?

_EINVAL The length argument was less than 0._
Caught this with `_OS\arg_assert()`.

_EFBIG or EINVAL The length argument was greater than the maximum file size._
I can't know what the maximum file size is. It might throw EINVAL (which is what `_OS\arg_assert($length <= $MAX_FILE_SIZE, '...')` would have thrown) or `EFBIG`. I would catch EFBIG and throw EINVAL instead, but the next entry would incorrectly have its error code changed.

_EFBIG The file is a regular file and length is greater than the offset maximum established in the open file description associated with fildes._
See previous entry.

_EIO An I/O error occurred while reading from or writing to a file system._
This is disks being disks...

_EBADF or EINVAL The fildes argument is not a file descriptor open for writing._
`File\open_write_only()` already checked for write permission.

Pull Request resolved: facebook#8930

Reviewed By: viratyosin

Differential Revision: D32103091

fbshipit-source-id: 60857e59146fe9ee1eb5c881a5d04da794b29569

nightly-2021.11.11

2021-11-10T23:38:39Z

fix error message when instance method/property called as static meth…

…od/property (facebook#8921)

Summary:
This PR:
- Update error message when an instance method/property is used as a static method/property
- Link to this [Issue](https://gist.github.com/shayne-fletcher/4cece69915f546ea68983172aaa7318e)

Pull Request resolved: facebook#8921

Test Plan: Imported from GitHub, without a `Test Plan:` line.

Reviewed By: Wilfred

Differential Revision: D32119355

Pulled By: shayne-fletcher

fbshipit-source-id: b313f1241debe4df7b77b247b3c3c86c0c7f887f

nightly-2021.11.10

2021-11-10T00:54:19Z

Raise error when a trait is <<__ConsistentConstruct>> but does not de…

…clare an explicit constructor

Summary:
Trait method copy-paste behavior breaks down with ConsistentConstruct, where unlike classes, traits to not generate a pure default constructor. This leads to a bug where a trait method can call `new static()` and assume the constructor is pure when it is really impure in the class that uses the trait.

This diff adds a flag to raise an error when a trait is <<__ConsistentConstruct>> without an explicit constructor. If the trait does have a constructor, then it's okay because the class that uses the trait will be forced to be consistent.

For the sake of completeness, I've added an option to raise this error on *all* classish declarations that do not explicitly declare a constructor, as the consistency is really more of a property of the constructor than of the classish.

Reviewed By: jamesjwu

Differential Revision: D32151766

fbshipit-source-id: 74fc75b64316286b66678707dccb471564546b90

nightly-2021.11.09

2021-11-09T02:15:28Z

Make object property write error message more generic to all contexts…

… without write_props

Summary: The next diff is moving towards a more generic solution where we always perform checks on object property writes whenever the write_props capability isn't available. The error message should be updated accordingly. This affects a lot of tests, so I'm moving the error message change into a separate diff for ease of review.

Reviewed By: jamesjwu

Differential Revision: D31979522

fbshipit-source-id: 8d32589c15abab0a0041e6a465321d0e5b43b531

HHVM-4.135.0

2021-11-08T18:05:47Z