Summary:
Fix an error about source directories being included in the include
path in add_thrift_cpp2_library. I don't know why this was failing for
fb303 and not for other projects, but adding a generation expression
appears to fix the issue.

Reviewed By: strager

Differential Revision: D15725024

fbshipit-source-id: 6c02fed6c6703733cf9e0b130c0f90b70e3ea300

Summary: Adds a callback interface to facilitate adding elision support for folly::Singleton. Planned to add context-aware elision support which will use an adaptation method based on the interface's callsite information (ie, the type of the Singleton instance, T, and the type of the callback function, F).

Reviewed By: nbronson

Differential Revision: D15970597

fbshipit-source-id: 1010322c64d1b7900b4bef5b35059238efabb071

Reviewed By: yfeldblum, luciang

Differential Revision: D16164723

fbshipit-source-id: ed0c4b2dddb09c8d97a8aca9379e4ea9b107a92c

Reviewed By: andriigrynenko

Differential Revision: D14637661

fbshipit-source-id: 0f8852e30ff554e9f0125e2d918054e4bc1e5af5

Reviewed By: yfeldblum

Differential Revision: D16214195

fbshipit-source-id: 4841b0ba3188f19aba7a0e2c2ffd04d2f5f55220

Summary:
TSAN: AtForkList::child() - ignore reads, writes and sync

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D16196384

fbshipit-source-id: 28ea3b9fdb317eaffcb428f6ae705d5c4e5de887

Summary:
Fix dyndeps.py to find dumpbin.exe in more situations.

Previously the code looked for dumpbin.exe under Visual Studio directories
named either `BuildTools` or `Community`.  On a system with an MSVC 2017
Professional install it is instead located under a directory named
`Professional`.  This updates the glob to allow any directory name here.

Reviewed By: pkaush

Differential Revision: D16207692

fbshipit-source-id: 1a57ec29653a89fd3e751b3e4408a298b4632b11

Summary:
We expose iobuf to Python via the folly.iobuf Python extension. The code for this extension has historically been in the fbthrift source tree. Move it to folly so that folly produces folly extensions and thrift produces thrift extensions.

Without this change we end up with the folly.iobuf Cython extension being packaged with thrift rather than folly, leading the need for a number of work-arounds to allow Python and Cython to find folly.iobuf without stopping their searches on folly.executor.

The tests for IOBuf python extension has been added to folly while maintaining the thrift-specific IOBuf tests in thrift.

Reviewed By: vitaut

Differential Revision: D14405645

fbshipit-source-id: 662a4e32c219f6d044bb6e903a2525ec1b4059c5

Summary: is_objfile() is used to find the executable files in the given project. Getdeps will only find and copy the dependencies of the binaries identified by this function. On Windows we will copy only the dependencies for an exe file.

Reviewed By: chadaustin

Differential Revision: D16185962

fbshipit-source-id: f6b5089401b242514a845e3a97b3804051d93c1c

Summary: Instead of using setCallbackAndDetach (which is hard to apply in all cases because of cancellation), this diff fixes releaseDefferedExecutor.

Reviewed By: yfeldblum

Differential Revision: D16189338

fbshipit-source-id: 47ef192dd0cec3c13824071c8ba7e1dd06968a70

Reviewed By: yfeldblum

Differential Revision: D15915100

fbshipit-source-id: afc131bdf143ac0eec15523e257545d63207cb34

Summary:
This are noisy and don't provide real value, so remove
the webhooks.

Reviewed By: yns88

Differential Revision: D16115486

fbshipit-source-id: 1daa2d78f4e786a42dcc5779ccd30c36e02d2445

Summary:
Some changes to get Poly compiling with VS2019 (and correcting an oversight from https://github.com/facebook/folly/pull/1174)

The change to `detail/TypeList.h` is straightforward I think.

The introduction of `getOpsImpl` I find a bit distasteful...I will remark that as of Visual Studio 16.2.0 Preview 3.0 it is not necessary, but it is still needed on Visual Studio 16.1.5 (latest release, non preview).

Orvid in your comment [here](https://github.com/facebook/folly/pull/1178#issuecomment-506864383)  you mentioned the question of supporting VS 2017 or VS 2019 given that Poly had no MSVC support at all beforehand. I re-downloaded VS 2017 on my machine to test against the fixes added here and the situation seemed discouraging with lots more errors and perhaps less obvious workarounds.

I have not made any changes to the CMake stuff for Poly on MSVC: https://github.com/facebook/folly/blob/master/CMakeLists.txt#L235

I'm not sure if once we resolve the issue above we might want to add some logic maybe [here](https://github.com/facebook/folly/blob/master/CMakeLists.txt#L63) to handle which version of MSVC is approved for poly; will wait for further direction on that.
Pull Request resolved: https://github.com/facebook/folly/pull/1182

Reviewed By: Orvid

Differential Revision: D16109504

Pulled By: yfeldblum

fbshipit-source-id: d20b242494b075ce91452215c2025584fe488d65

Summary:
Test AsyncSocketTest.getBufInUse was throwing exceptions, I believe
this should fix those issues. The problem appeared to be that the socket
connection did not always work immediately so we needed to call loop() on the
event base so that an async connection could complete.

Reviewed By: yfeldblum

Differential Revision: D16052111

fbshipit-source-id: 9793e613eea5b17cb3ab00605355102b2f8807d8

Summary:
Folly already has its own lightweight implementation `IteratorFacade`. It depends only a few STL headers thus saves compilation time.
Pull Request resolved: https://github.com/facebook/folly/pull/1187

Reviewed By: LeeHowes

Differential Revision: D16147453

Pulled By: yfeldblum

fbshipit-source-id: 9559a095e242ee7e16659558d505777159f6e534

Summary: Add MicroSpinLock TSAN annotations

Reviewed By: yfeldblum

Differential Revision: D14578441

fbshipit-source-id: e2c9bc1806550d003cc659a86d214c089464f126

Summary:
Context: migration of fbcode from folly::gen to range-v3 by way of pipe-adapters ("pipe fittings") that allow a `|`-based pipeline mixing {std-containers and/or range-v3} with folly::gen, e.g.,

```
auto result = myVec              // anything consistent with range-v3 or these adapters
    | ranges::view::filter(...)  // zero-or-more range-v3 pipe-elems
    | <adapter-goes-here>        // <==**one of the pipe-adapters provided by this task**
    | folly::gen::blah();        // trailing pipe-elems are folly::gen
```

Goal of this task: rename the pipe-adapter folly::gen::detail types so those names are consistent with the names of the corresponding folly::gen::objects.

Reviewed By: yfeldblum

Differential Revision: D16138397

fbshipit-source-id: 3e6145f5bb35c8d2bd14a9a3eb645e153743d499

Summary:
Relocate "folly::gen to range-v3" pipe-adapters into the corresponding adapter-struct (fix compile-time errors, plus improve clarity about the linkage between the `operator|` and corresponding type).

Context: pipe-adapters ("pipe fittings") that allow a `|`-based pipeline mixing {std-containers and/or range-v3} with folly::gen, e.g.,

```
auto result = myVec              // anything consistent with range-v3 or these adapters
    | ranges::view::filter(...)  // zero-or-more range-v3 pipe-elems
    | <adapter-goes-here>        // <==**one of the pipe-adapters provided by this task**
    | folly::gen::blah();        // trailing pipe-elems are folly::gen
```

This diff relocates those folly::gen-to-range-v3 adapters.

Reviewed By: yfeldblum, ericniebler

Differential Revision: D16053008

fbshipit-source-id: 078a95990d5277ac0c4e02452cd8fd36bead8306

Reviewed By: yfeldblum

Differential Revision: D16138503

fbshipit-source-id: 49243eeb6eb24417c912b89beb84d15bae73053f

Summary:
StandardLogHandlerFactory has a good amount of logic in it for handling
options. It would be nice to reuse it when specifying a custom Formatter.

This also exposes the WriterFactory from StreamHandlerFactory, so that a user
can re-use the code to create the default LogWriter when using a custom
Formatter.

Reviewed By: yfeldblum

Differential Revision: D16074437

fbshipit-source-id: d79947e2fe93b8920b83294438a88c4dd871986b

Summary:
Mapping scratch dir <from> -> <to> show up in the output of all the show dir commands on Windows, so removing it.
example: getdeps.py show-inst-dir eden

Reviewed By: wez

Differential Revision: D16092494

fbshipit-source-id: 910288a8d23c1d68c5e70b7b2dbb36ef53a326fc

Summary: This adds a subclass to copy the dynamic dependencies on Windows.

Reviewed By: wez

Differential Revision: D16110433

fbshipit-source-id: 14d876947f3ec504382fef0d459367a7119ff6cb

Reviewed By: yfeldblum

Differential Revision: D16099521

fbshipit-source-id: da89c9954037c168f7591353e42b2632af0b8b31

Summary:
This diff adds a `fixup-dyn-deps` subcommand that is intended to
aid in packaging on multiple platforms.

Its purpose is to copy a set of executable object files from the getdeps
installation directories and place them into an installation staging
area that will then be used to create some kind of package (rpm, tarball etc.).

The dynamic dependencies of the executables are determined and also copied
into the destination area, and the important part: the execute is rewritten
such that it will load the deps out of an alternate installation prefix.

The implementation of this command draws on similar scripts in use for
the watchman and eden packaging on windows and macos.  This diff adds
linux support using the `patchelf` utility.

Reviewed By: pkaush

Differential Revision: D16101902

fbshipit-source-id: 5885125971947139407841e08c0cf9f35fdf5895

Summary: I want to use this logic outside of a builder implementation

Reviewed By: pkaush

Differential Revision: D16101914

fbshipit-source-id: db3c9ac6c84a92ab84a18dddb931953b0a51f127

Summary:
The intent is to use this in a future diff to make packaging a first
class concept; it can be used similarly to how we munge dynamic deps on darwin
systems.

Reviewed By: shri-khare

Differential Revision: D16099931

fbshipit-source-id: c66f994b7c07e903fbf2989946b17a0991e12a91

Summary:
wait.h is a GNU header. The POSIX one is sys/wait.h. Fixes musl warning:

warning redirecting incorrect #include <wait.h> to <sys/wait.h>
Pull Request resolved: https://github.com/facebook/folly/pull/1183

Reviewed By: wez

Differential Revision: D16097571

Pulled By: yfeldblum

fbshipit-source-id: 751e4929bc9f00c99c160be9a7dd904e57ad40ce

Summary:
We're seeing a failure on macOS in a CI environment but don't have much context:

```
Stderr:
+ GETDEPS=opensource/fbcode_builder/getdeps.py
+ opensource/fbcode_builder/getdeps.py test --facebook-internal watchman
Traceback (most recent call last):
  File "opensource/fbcode_builder/getdeps.py", line 436, in <module>
    sys.exit(main())
  File "opensource/fbcode_builder/getdeps.py", line 422, in main
    return args.func(args)
  File "opensource/fbcode_builder/getdeps.py", line 342, in run
    builder.run_tests(install_dirs, schedule_type=args.schedule_type)
  File "/data/sandcastle/boxes/trunk-hg-fbcode-fbsource/fbcode/opensource/fbcode_builder/getdeps/builder.py", line 372, in run_tests
    buck_test_info = list_tests()
  File "/data/sandcastle/boxes/trunk-hg-fbcode-fbsource/fbcode/opensource/fbcode_builder/getdeps/builder.py", line 352, in list_tests
    data = json.loads(output.decode("utf-8"))
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py", line 338, in loads
    return _default_decoder.decode(s)
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
```

Add some more context to that error message so we can learn more.

Reviewed By: pkaush

Differential Revision: D16061528

fbshipit-source-id: 23603a5d18651d20641ef1987b7094e73a9b1dbe

Summary: On Windows "--vcvars-path" can be passed to point to the toolchain we want to use.

Reviewed By: wez

Differential Revision: D15926044

fbshipit-source-id: 2b0cde793f7c7f8473b78afde8794640bae351f3

Reviewed By: udippant

Differential Revision: D16075865

fbshipit-source-id: 172aed7ebbfce987c78eea06e588048b0e2a755f

Summary:
NotificationQueue, although mostly not used as such, is a multi consumer queue and it's missing benchmarks for that part.

There where also a couple of issues with original benchmark which this diff addresses:
1. Benchamrks used to do N * number of producers number of iterations and didn't report increased iteration count back to benchmark
2. Benchmark would not run the same case during whole benchmark time as producers where stopped as soon as they produced enough request and consumer would finish without contention

Since these are very tight loops I added a busy loop param which can be varied the same way as batching parameter.
This param adds some work in a form of a busy loop in both producers and consumer to make benchmarking cases, where producers/consumers are actually doing something except from posting to the queue, easier.

Reviewed By: yfeldblum

Differential Revision: D16071580

fbshipit-source-id: c75f2dd9ae8617be09834cdf153a4b4ae06aaaca

Summary: While congested throughput is important it is also important not to regress non congested path too much.

Reviewed By: aary

Differential Revision: D16005428

fbshipit-source-id: 7b98a7ef253fc306b3097f7236b57a5d453ed15d

Summary: [Folly] Check for max value in test semaphore, beyond which posts cannot be tolerated.

Reviewed By: aary

Differential Revision: D15938166

fbshipit-source-id: 1f3fee97a9662dafc5b434c0449831147aa3c976

Summary:
Remove all the autoconf files.
And fully switch to the cmake build

Reviewed By: udippant

Differential Revision: D16066986

fbshipit-source-id: 9e3082dded77ce85449cf5a3a03bed31c16b711f

Summary:
Folly's `folly/lang/Align.h` header defines `folly::max_align_t`, which is usually taken from stdlib. This is to correct an error in legacy implementations of `std::max_align_t`, by logically reconstructing the maximum alignment value in a constexpr context.

`max_align_t` depends on the function `detail::max_align_`, which is supposed to implement a recursive max value function using templates. However, the expression

```
!(a < e) ? a : max_align_(e, es...)
```

does not recursively compute the maximum value over `a`, `e`, `es...`. This expression actually selects the first value that is followed by a lower value.

This error prevents folly from compiling on newer versions of clang, targeting x86, because `folly/CachelinePadded.h` statically checks `max_align_t` in an assertion, and then fails, because it thinks that `AtomicStruct<LifoSemHead, atomic>` is over-aligned.

This corrects the implementation to:

```
!(a < e) ? max_align_(a, es...) : max_align_(e, es...)
```

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

Reviewed By: Orvid

Differential Revision: D16079107

Pulled By: yfeldblum

fbshipit-source-id: 13adbd6d1c117b3c547e7116216ee1069129b3c7

Summary:
The source we were downloading from (netfilter.org) should work, but
unfortunately, is donw. This is causing getdeps FBOSS builds to fail. For now,
download from a mirror which seems to be up.

If this becomes a frequent issue with this repository/others, we can consider a
different solution.

Also, not sure how lfs pointer edit was missed by previous commit, added here.

Reviewed By: phshaikh

Differential Revision: D16070052

fbshipit-source-id: dd9278254c77e1a5845ca331a9eeb36f2bf03071

Reviewed By: yfeldblum

Differential Revision: D16054275

fbshipit-source-id: 266f2244fd4c28e1726f4f84d32d4f5d6856ec26

Summary:
Second attempt at https://github.com/facebook/folly/pull/1173

This time the class template specializations are guarded with the `__cpp_noexcept_function_type` feature test macro to maintain compatibility with C++14.

Open to replacing the raw macro with something like `FOLLY_POLY_NOEXCEPT_FUNCTION_TYPE` but that was not my first approach since it's more characters and there is not an extra case to test like with `FOLLY_POLY_NTTP_AUTO`.
Pull Request resolved: https://github.com/facebook/folly/pull/1178

Reviewed By: yfeldblum

Differential Revision: D16057403

Pulled By: Orvid

fbshipit-source-id: 9b538c0f1b0614e69447202d1e4d60ed3fa709cb

Summary: `_mm_crc32_u64` requires SSE 4.2, not just any SSE.

Reviewed By: vener91

Differential Revision: D16032673

fbshipit-source-id: 13cb6299e14184b30a9a04f2644aee2f0cd1a60e

Summary:
Clang defines `_MSC_VER` on Windows, but it is not MSC.

```
% ./third-party/toolchains/llvm/8.0.0/bin/windows/clang.exe -march=corei7 -dM -E -x c empty | grep MSC
#define _MSC_BUILD 1
#define _MSC_EXTENSIONS 1
#define _MSC_FULL_VER 191225835
#define _MSC_VER 1912
```

We are not allowed to define `__SSE4_2__` in clang when clang assumes older arch, because in that case it refuses to compile SSE intrinsics, there is a couple of places in folly where we assume defined `__SSE4_2__` to use SSE4.2 intrinsics.

On the other hand clang defines `__SSE4_2__` itself when it is available:

```
% ./third-party/toolchains/llvm/8.0.0/bin/windows/clang.exe -march=corei7 -dM -E -x c empty | grep SSE
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE4_2__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSSE3__ 1
```

This is an example clang error on Windows:

```
folly/container/detail/F14Table.h:1098:23: error: always_inline function '_mm_crc32_u64' requires target feature 'sse4.2', but would be inlined into function 'splitHash' that is compiled without support for 'sse4.2'
      std::size_t c = _mm_crc32_u64(0, hash);
```

Reviewed By: vener91

Differential Revision: D16038436

fbshipit-source-id: 8728a8d91cadb936c9e244795c9270943fe005ad