Summary:
Pull Request resolved: https://github.com/facebookexperimental/rust-shed/pull/26

Pull Request resolved: https://github.com/facebookexperimental/eden/pull/104

No need for the checked in generated code anymore

Successful external CI Linux run on Git Hub PR: https://github.com/facebookexperimental/eden/runs/5130405984?check_suite_focus=true

Mac PR run fails with a SSL cert issue, will look separately

Reviewed By: chadaustin, mitrandir77

Differential Revision: D33840545

fbshipit-source-id: eafc2a0e2191d438fd828adeebc2e318d319025f

Summary: This change should not make a functional difference to any existing callers. The underlying data structure stores a TimePoint.

Reviewed By: yfeldblum

Differential Revision: D34060591

fbshipit-source-id: b2b4d7f0d7fed8220cffb6b1dba5082d21073686

Reviewed By: pranavtbhat

Differential Revision: D34103812

fbshipit-source-id: e02b728d468bf091e8b4521f8f8746a986a2130d

Summary: Define at least one virtual method in a cpp file.

Differential Revision: D33891879

fbshipit-source-id: 3d2e3177b112c5fc7b2b84ed8bc41c5d0e15127e

Summary:
`EDFThreadPoolExecutor` is currently the only implementation of
`SoftRealTimeExecutor`, and it implements multi-add functionality (which
allows us to wake up idle threads just once on batch-add, as well as reduces
planning overhead), let's expose this at an interface level.

Reviewed By: ot, luciang

Differential Revision: D34095644

fbshipit-source-id: ba59300a4c51599d7c6cbfaaabe3d6013be7c37f

Summary:
Watchman advertises support for FreeBSD but it's regressed a couple
ways. Ensure it builds on FreeBSD again with a Vagrantfile.

Reviewed By: ahornby

Differential Revision: D33989289

fbshipit-source-id: ff906bc219974bafbc349740ce6bddfe5bd2908f

Summary: Add some basic support for FreeBSD to getdeps.

Reviewed By: ahornby

Differential Revision: D33989129

fbshipit-source-id: 42ff5f160b7e19c12196bb2e52a726f7815487bd

Summary: `unsigned long` and `size_t` are not the same type on Clang Windows.

Reviewed By: yfeldblum

Differential Revision: D34086667

fbshipit-source-id: adba5d960cb4c8b8e13b62f419d5b4179b1525e1

Summary:
This is an old copy of Mercurial, saved to keep the Mercurial servers running
until we completely pull the plug on them. Neither EdenFS nor EdenSCM should
depend on it.

Reviewed By: mitrandir77

Differential Revision: D34081890

fbshipit-source-id: 78e2c07fae75b3f25aa492ece03308f736d42769

Summary:
In a way which also happens to improve build speed.

It turns out that the bulk of the improvement comes from removing the use of `std::is_nothrow_move_constructible` since it may internally have a `std::declval` in there. But that's not the only source of improvements.

```name=trunk
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     8,367,373,932      instructions:uP
```
```name=branch
$ foundation/scripts/run-perf-compile --syntax folly/futures/test/FutureTest.cpp
     8,101,850,897      instructions:uP
```

Reviewed By: luciang

Differential Revision: D32973629

fbshipit-source-id: 37c27763a4f622750719db11fee7cb23c0b0291e

Summary:
libevent 2.1.8 is not aware of the arc4random deprecation on FreeBSD,
so upgrade to the latest.

Reviewed By: xavierd

Differential Revision: D33984680

fbshipit-source-id: b7d2b869bc47d49d8f29df1b318d8f2067204aae

Summary: Adding AsyncSSLSocket::performReadv

Reviewed By: afrind

Differential Revision: D33717297

fbshipit-source-id: 413f50fcaf1d59cec98765a095a5a5964f634e23

Summary:
The new boost has an MSVC detection algorithm that 1) I don't
understand and 2) does not even seem deterministic. Since our internal
builds are pinned to vc142, force that in the manifest.

Reviewed By: fanzeyi

Differential Revision: D34085081

fbshipit-source-id: d8ce4d8e28aad14f6fa60f9227dafb546ce321e5

Summary:
Pull Request resolved: https://github.com/facebookexperimental/eden/pull/101

public_autocargo already existed for edenfs, but needed to move up a level so to make edenfs thrift definition visible via autocargo.

Reviewed By: markbt

Differential Revision: D32693522

fbshipit-source-id: 4c070cfa2d6294a28c17697338f0309dcab1576f

Summary:
Pull Request resolved: https://github.com/facebookexperimental/eden/pull/103

Automate maintenance of the edenscm_* github actions yamls

Add job file and name options and support for the Rust install section

Reviewed By: fanzeyi

Differential Revision: D34044422

fbshipit-source-id: 7d5f07d37bab1eff5de30a88e710dbf7479ca192

Summary: Fix the getdeps.py  generation sub command and regenerate github actions before making changes to support actions generation for eden_scm

Reviewed By: fanzeyi

Differential Revision: D34044243

fbshipit-source-id: 0039d04f25af4c842145dc142dae6b9996fc8046

Summary:
For global variables with nontrivial destructors, the compiler inserts calls to `atexit` to destroy the variables at shutdown time. For global variables with trivial destructors, the compiler elides such calls. Revise `Indestructible` to have a trivial destructor.

Some compilers optimize further and remove such calls even for some nontrivial destructors, but not all do so.

Also remove move-construction and move-assignment. And remove actual `constexpr`-constructibility since `::new` is not a constant expression.

Reviewed By: chadaustin

Differential Revision: D34026842

fbshipit-source-id: 9ab2f957cbe9a67809a6c99e6b9370c1f4315777

Reviewed By: ot, luciang

Differential Revision: D33864764

fbshipit-source-id: 9839f578bd0fe5e8f69d5299287a59cb471f8cf3

Summary: Whether a value is passed in registers also depends on its size, not just whether it is trivially copyable. (It also depends on its position in the arg-list but that is another step in complexity.)

Reviewed By: luciang

Differential Revision: D33079529

fbshipit-source-id: ae7383d61491001e54892cf077e45556801bdcf4

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