Differential Revision: D34056336

fbshipit-source-id: adf4c0b96d6fd3f5e15c7bfefe7e908e85baf5b1

Summary:
It turns out that instantiating this function declaration template so widely measurably affects build speed. Prefer alternative techniques, such as `FOLLY_DECLVAL`.

```name=trunk
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     8,462,001,355      instructions:uP
```
```name=branch
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     8,362,569,934      instructions:uP
```

Reviewed By: Gownta, luciang

Differential Revision: D32973365

fbshipit-source-id: 6930f75e04e0bb9ac4216b08645e67b98ca2c2f3

Summary: Coalesce the inline-asm. Use invokers.

Reviewed By: Gownta

Differential Revision: D32302511

fbshipit-source-id: 6edf75c6ef820ed80e751d965174e5acfaac957e

Summary:
Define `heap_vector_map` and `heap_vector_set`. These feature a fast lookup (find operation) which does not rely on `std::lower_bound` or similar to find keys. Map elements are not laid out in sorted order. Instead, they are laid out in heap order, which is also known as Eytzinger order. A heap order layout is optimal to maximize memory and cache locality of lookup operations.

A heap vector set containing the elements 0-7 lays out the elements as:

                                     elements  in sorted order
  heap_container[0]  =  4 <-- middle
  heap_container[1]  =  2
  heap_container[2]  =  6
  heap_container[3]  =  1
  heap_container[4]  =  3
  heap_container[5]  =  5
  heap_container[6]  =  7 <-- max
  heap_container[7]  =  0 <-- min

`heap_vector_map` (referred below as HM) is almost a drop-in replacements for `sorted_vector_map` (referred as SM). All SM APIs are supported, and are semantically equal, with very few exceptions.

Although HM works correctly for any key value SM supports, the speedup of find operation (random key search) is typically limited to maps with small key types with comparison operations subject to inlining. Measurements suggest up to 2x speedup of find operation for HM compared to SM.

The key tradeoff is that HM has slower insertion and removal operations and slower iteration. Prefer HM if updates and traversals operations are rare, and lookups are the dominant operation. Of course, SM itself has slow insertion and removal operations so, if these operations are sufficiently common, another map type entirely would be preferable.

Key similarities:

1) They have the same in-situ sizes: `sizeof(HM) == sizeof(SM)`.
2) Insertions and removals. As expected, these operations are slower for HM. Both SM and HM need to move elements while preserving sorted or heap order but the SM operation can be much simpler.
3) A fast construction of HM from a sorted vector or from a SM.
4) An iterator that follows sorted order compatible with SM. This is complex, though. When sorted iteration order is not required, it is faster to use the enclosed container's iteration order.

Key differences:

1) iterate() is a new API that provides the iterator range of the container vector. iterate() enables the fastest traversal of the heap container elements. For example,
          for (auto& element : HS.iterator()) { // traversed as laid out in memory
              std::cout << e << ", ";
           }
for above examples, the loop prints:  4, 2, 6, 1, 3, 5, 7, 0,
           for (auto& element : HS) { // key-sorted
              std::cout << e << ", ";
           }
for above examples, the loop prints:   0, 1, 2, 3, 4, 5, 6, 7,

2) data() is purposely not provided because it does not point to the first elements. If the start address is needed, use instead HM.iterate().data()

Reviewed By: Gownta

Differential Revision: D32128733

fbshipit-source-id: 1df7372720b969ee7a84004ded101db132e0c224

Summary:
It turns out that `std::decay` becomes expensive when as widely instantiated as it is.

```name=trunk
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,336,421,499      instructions:uP
```

```name=branch
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,287,269,480      instructions:uP
```

Reviewed By: Gownta, luciang

Differential Revision: D32973204

fbshipit-source-id: 75d52fd5ced58f50518913d3c00709bcee27c87b

Reviewed By: ahornby

Differential Revision: D34030118

fbshipit-source-id: 2229527eebb147a9c2eea90be78ab72e63e2fe3f

Summary: Folly has an optional libsodium dependency.  Declare that in folly getdeps manifest so that the relevant code is built and tested in CI.

Reviewed By: yfeldblum

Differential Revision: D34028478

fbshipit-source-id: 5e7c2f86602b94a3a975907adf8bd04f49ec33c0

Summary:
There are many lambda types so that can be a lot of instantiations. This shows up with futures, which use `Function` under the hood with lambdas.

It is not as helpful to avoid `std::move` completely - it is primarily important to avoid it over callables, since these locations are widely-instantiated but may also be the only instantiations over the callables.

```name=trunk
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,359,421,839      instructions:uP
```
```name=branch
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,331,468,279      instructions:uP
```

Reviewed By: Gownta, luciang

Differential Revision: D32971147

fbshipit-source-id: b2ce1325330ed59d9fb23fed48476fddf24e7854

Summary:
A utility function for modeling explicit floating-point-to-integral conversions but without requiring the destination type to be spelled if it can be inferred from context.

Useful when it is important to highlight one abstract category of a conversion, that it is a floating-point-to-integral conversion, and when highlighting the concrete types involved tends to hide the category.

Like `to_narrow`, which models explicit integral same-sign narrowing conversions.

Differential Revision: D33992808

fbshipit-source-id: 5010d84eb6382087250a815d223ab42adfa26ca7

Summary: Having the complex conditions extracted to helper variables or types leaves the function declaration simpler.

Differential Revision: D33992433

fbshipit-source-id: f51775bc2901bb232c1bbd3136eb988e234c8af2

Summary: Expose `try_emplace` to give clients signal on whether an element was actually inserted. This will allow for more efficient code without needing to check for existence before inserting.

Reviewed By: yfeldblum

Differential Revision: D34006997

fbshipit-source-id: 3bdb7d4d81c19d0fcd7c82f194f1f695b79cf57b

Summary: And other fixes. Because Hyrum's Law comes for all.

Reviewed By: vitaut

Differential Revision: D34010783

fbshipit-source-id: 95c56f24ef4b129b2758d4ec465366cd09acac93

Summary: Methods should be `public`.

Reviewed By: ot, luciang

Differential Revision: D34014408

fbshipit-source-id: 49adaa3a01189f5c9dee7082a872147386a95548

Summary:
We need to reset the zerocopyReadDisabled_ flag every time we switch between read callbacks since some of them might support a mem store. we verify the support again on the next read attempt.

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D33957906

fbshipit-source-id: 37a962c6187502e241288ea179f04ca11c4c27b9

Summary:
* `BadExpectedAccess<void>` inherits `std::exception` and `BadExpectedAccess<E>` inherits `BadExpectedAccess<void>`.
* Copy-constructor, copy-assignment-operator.
* Member `error` returns a reference.

Paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0323r11.html.

Reviewed By: Gownta

Differential Revision: D33907293

fbshipit-source-id: 5002dfa548840431f957540bec23d95f34c9a68d

Summary: Some compilers may not understand `decltype(function)` when they would understand `decltype(&function)`, in particular, when that function has an exception specification.

Differential Revision: D34000718

fbshipit-source-id: 8adf2846d9ed877109a35a25c79b694cc7ed4e6f

Summary: {fmt} is moving away from relying on implicit conversions because they may introduce ODR violations and not supported consistently. For example, `fbstring` can be formatted via an implicit conversion or via `operator<<`. To make sure this doesn't happen and make the code compatible with future versions of {fmt} add a `formatter` specialization for `fbstring`. This is consistent with `folly::StringPiece` which already has such specialization.

Reviewed By: ot

Differential Revision: D33994222

fbshipit-source-id: 8150415ef45bd97b24aa12dd209b56c977c148c6

Summary: Fix some typos and expand some of the descriptions.

Differential Revision: D33959231

fbshipit-source-id: 70c7bb4f15757c75f28d00271af325b440da8e19

Summary:
`Function` requires an instantiation of a control function for every unique callable type. There are two control functions, named `execSmall` and `execBig`.

But instantiation is expensive for build speed and build size - especially instantiation per unique callable type.

An hypothesis is that it is common for callable types to be trivially-copyable. In particular, that it is common to have lambdas with implicit by-reference captures and no other captures, as `[&] { /* ... */ }`.

So we introduce a new dispatch class, `DispatchSmallTrivial`, with a member function `exec` which is instantiated as few times as possible and which is used for all trivially-copyable callable types.

Reviewed By: ot, luciang

Differential Revision: D32932586

fbshipit-source-id: 34ecad6b6bcbbc3ed379e3d32babf04c91d76557

Summary: Make the --facebook-internal flag value available from BuildOptions so can have jobs of both values where required

Reviewed By: xavierd

Differential Revision: D33945588

fbshipit-source-id: 5d0e1b42973bd3e411a4a71075915bdb2755f0eb

Summary: CentOS Stream 8's cmake 3.20.2 boost rules don't find the system boost with just BOOST_ROOT_1_78_0 (make sense, the system boost is 1.69),  so set BOOST_ROOT_1_69_0 as well

Reviewed By: chadaustin

Differential Revision: D34000244

fbshipit-source-id: 73df3b6b9f1c091fd70fd61bc7169c5f77ed632b

Summary: Not sure if necessary today, but some compilers have historically required this.

Differential Revision: D33992255

fbshipit-source-id: 14cec23d7e6d29f7f15934e27b004f002cac71ef

Summary:
In order to speed up build times on a mac, add homebrew support to
getdeps.

Homebrew packages can be declared in a manifest using the `homebrew` header.

Futher, ahornby has added manifest entries for homebrew packages which are
included in this diff and also included a change to use the correct version of
openssl. Without this openssl change, homebrew cmake configure finds an old
openssl 1.0.2 install.

This diff provides a 2x speed up for building folly:

Timings for clean getdeps folly build on mid-2018 2.9Ghz i9 6 core intel macbook pro with 32GB RAM:

With new homebrew system deps:
```
rm -rf /Users/ahornby/.scratch/UsersZahornbyZfbsource/fbcode_builder_getdeps/
time ./opensource/fbcode_builder/getdeps.py build --allow-system-packages folly
real	17m39.329s
user	76m10.317s
sys	5m50.163s
```

Without:
```
rm -rf /Users/ahornby/.scratch/UsersZahornbyZfbsource/fbcode_builder_getdeps/
time ./opensource/fbcode_builder/getdeps.py build folly
real	32m10.344s
user	105m53.448s
sys	15m57.858s
```

Reviewed By: ahornby

Differential Revision: D33842632

fbshipit-source-id: ac785d4a8dcfa31b77292bddd9e747022ac36e3b

Summary: Add expressions for shipit entries so that we can map different directories if needed

Differential Revision: D33947996

fbshipit-source-id: e765769ae5a6ab90055b63284e538b965d6071b3

Summary: Create a new fbsource property for manifests so we can still use monorepo rust toolchain when running builds with --no-facebook-internal

Differential Revision: D33945559

fbshipit-source-id: 606af62e03d09c3529018af4478bcafecd0cd640

Summary: Newly a thing with `fmt` v8.

Differential Revision: D33995623

fbshipit-source-id: 4560f1498a8f8253ab572105a441b735d53d776f

Summary: Boost 1.69 does not build on Fedora 35, so upgrade to Boost 1.78.

Reviewed By: ahornby

Differential Revision: D33855670

fbshipit-source-id: 85469a835a1dab1a7d5222413b1f1349bdcff280

Reviewed By: singhsrb

Differential Revision: D33982894

fbshipit-source-id: 5ec3f1555a551f3931983fde844346293704231c

Summary:
If a getdeps project creates a bind mount in a subdirectory, we don't
want the shipit transformer to copy all of the bind mount's contents
to the ship-transformed output.

This manifested when I was using Vagrant inside of Watchman and
`getdeps.py fetch watchman` would copy all of the Vagrant VMs too.

Reviewed By: ahornby

Differential Revision: D33855553

fbshipit-source-id: e2bc50ecfe0d067490c95be05d074d6a844f30d5

Summary:
cpptoml is unsupported and is missing an #include. Switch to a patched
fork so we build on recent gcc, including Fedora 35.

Reviewed By: xavierd

Differential Revision: D33855455

fbshipit-source-id: 48675a116fc1f53246c6bf206f1deee32bd7d6c3

Summary:
There's no reason to block a getdeps build on prefetching its sources,
so issue all prefetches in the background.

Reviewed By: genevievehelsel

Differential Revision: D33855396

fbshipit-source-id: 1ba01b0587e9bc0e74e6bba5b8571af76bf2516d

Summary: Check before redefining TCP_ZEROCOPY_RECEIVE

Reviewed By: henrywang8atfbdotcom, kevin-vigor

Differential Revision: D33982730

fbshipit-source-id: 1f6a6d95e247e0fe824d853c4504ef0bd17e76bf

Summary: Call scheduleImmediateRead() outside of the loop

Reviewed By: simpkins, kevin-vigor

Differential Revision: D33981511

fbshipit-source-id: d71cb9ac3f1f5eebae82195d5c93a2a90e80a636

Summary: To avoid unnecessary forward-declarations.

Reviewed By: Gownta

Differential Revision: D32015253

fbshipit-source-id: be8d5db93aebcd187dad379cd59ec69e2e274731

Summary: Fix typo

Reviewed By: yfeldblum

Differential Revision: D33956691

fbshipit-source-id: 49b0c59554eb1d45f856e2e2b2a3598f74715179

Summary:
The type-erased Function is widely used with lambdas and the type of every lambda is unique. Template instantiations are costly for build speed so, for the parts of Function which interact with lambdas, we choose techniques to optimize build speed.

In particular, we avoid the extra layer of constructor templates which must be overload-tested and instantiated. The existing design of the extra layer was clean - it effectively used tag-dispatch and was able to deduplicate code with the coercing constructor. However, the choice of techniques was not optimal for build speed.

```name=trunk
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,407,492,259      instructions:uP
```

```name=branch
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     6,303,165,111      instructions:uP
```

Reviewed By: Gownta, ot, luciang

Differential Revision: D32940920

fbshipit-source-id: 742cb67b994e7c3e6c070254386f3cdf5dffa38c

Summary: We need it for lego

Reviewed By: yfeldblum

Differential Revision: D33910794

fbshipit-source-id: 2a326f8fc41baae0db68657331f93b3d8124b8d8

Summary:
When trying to bring react-native-macos up to date with 0.66, I was running into an issue getting RNTester to compile due to an error regarding redefining `clockid_t`. Other people have been seeing similar issues as per [these search results](https://github.com/facebook/folly/issues?q=clockid_t).

The history behind this appears to be as follows:

Several declarations in `<time.h>` were not available on Apple platforms until macOS 10.12 and iOS 10, which is why Folly needs to check the minimum version and set `FOLLY_HAVE_CLOCK_GETTIME` as needed. The problem is, the current logic as it stands right now is to set `FOLLY_HAVE_CLOCK_GETTIME = 1` (which implies that we don't need to declare them ourselves as the OS provides them for us) if...
* ...we're building for macOS, and the minimum required version is less than 10.12, or...
* ...we're building for iOS, and the minimum required version is less than 10.

However, this doesn't make any sense. This is saying that we don't need to declare these missing APIs if we could be compiling Folly for use on an older version (i.e., macOS 10.11/iOS 9 or earlier), which is totally wrong! Instead, we ought to be checking if the versions are *at least* macOS 10.12 or iOS 10.

React Native currently works around this by eliminating the minimum version check entirely with [this PR](https://github.com/facebook/react-native/pull/32715/), which is certainly a valid local fix ([the minimum iOS version for React Native apps is currently iOS 11](https://github.com/facebook/react-native/blob/1b31d6bb582768ccbe92d3c1a9e43354a8c531e5/template/ios/Podfile#L4)), but doesn't solve the problem at its core. This PR does solve the problem.

I have not tested building this with a minimum version below the above thresholds for use on a modern version of macOS/iOS, but considering the discussion in https://github.com/facebook/folly/issues/1545, I think we should be safe to ignore these older versions from now on.

Pull Request resolved: https://github.com/facebook/folly/pull/1688

Reviewed By: yfeldblum

Differential Revision: D33483705

Pulled By: Orvid

fbshipit-source-id: 0fe7c556af7e5b79a7679f75d003cf81a8f412ce

Summary: ^

Reviewed By: praihan

Differential Revision: D33807636

fbshipit-source-id: 0a0aaa533387284f758daf057529aaa7ddc3ce04

Summary:
Add support for Linux TCP zerocopy RX

(Note: this ignores all push blocking failures!)

Reviewed By: simpkins

Differential Revision: D32741177

fbshipit-source-id: 412981fdd4a27437d6f22a80dc7c5fc864335ddf