Summary: The eventual plan will ban the use of `to/fromFd` on `NetworkSocket` when compiling on Windows.

Reviewed By: yfeldblum

Differential Revision: D14592244

fbshipit-source-id: cbf965f6822cbd5b6b1098c7dab9ab65aafd8192

Summary:
1) There's no need to exit the loop if we encounter and IOBuf of length 0.
2) We should do `n <= tailroom()` instead of `n < tailroom()`.

Reviewed By: yfeldblum

Differential Revision: D14715582

fbshipit-source-id: 9a30454bd536929414f7c9013dbcf6e59e6e7f2c

Summary:
was trying to see if I could repro the issue described here:

Refs: https://github.com/facebook/folly/issues/1092

Reviewed By: yfeldblum

Differential Revision: D14702579

fbshipit-source-id: d90cbf5742883a26d9ac5dbfd56eed1965cbc64e

Summary:
Running down various warning/error issues is proving
to be a tiresome game of wackamole.   Here's the latest issue:

```
folly/container/test/F14TestUtil.h:400:16: error: ?void* mem
      std::memcpy(p, &n, sizeof(std::size_t));
      ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:64,
                  from /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/char_traits.h:39,
                  from /opt/rh/devtoolset-8/root/usr/include/c++/8/string:40,
                  from /opt/rh/devtoolset-8/root/usr/include/c++/8/stdexcept:39,
                  from /data/users/wez/scratch/dataZusersZwezZfbsource/fbcode_builder_getdeps/shipit/folly/folly/container/F14Map.h:30,
                  from /data/users/wez/scratch/dataZusersZwezZfbsource/fbcode_builder_getdeps/shipit/folly/folly/container/test/F14MapTest.cpp:17
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_pair.h:198:12: note: ?struct std::pair<const std::basic_string<char>, int>? declared here
      struct pair
            ^~~~
```

The targeted solution is to use `-Wno-class-memaccess` as we do with our
internal builds, but that is a gcc-specific option that fails when used with
the apple clang compiler.

The simplest option is just to disable warning->error promotion in
the cmake build, as it feels like a losing battle to keep chasing
the different combinations/permutations.

Reviewed By: yfeldblum

Differential Revision: D14702575

fbshipit-source-id: d8daa6c9588e7c84c991a0ef86baf700bd32fe8c

Summary:
move the FindGMock to the common cmake library and adjust
folly and wangle to consume it from there.

Reviewed By: strager

Differential Revision: D14710329

fbshipit-source-id: 35ac9d6d2ec03468f389f5b9f1c126b007c7c798

Summary:
In D14702587 I made a change to workaround an ICE in gcc 8.
It turns out to be a gift that keeps giving; with the code as-is
on windows we now encounter:

```
folly\io\async\test\AsyncTimeoutTest.cpp(29): error C3493: 'expected' cannot be implicitly captured because no default capture mode has been specified
```

Adding `expected` to the capture list yields this error with gcc, either with or without the reference:

```
stderr: folly/io/async/test/AsyncTimeoutTest.cpp:29:45: error: lambda capture 'expected' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
      AsyncTimeout::make(manager, [&value, &expected]() noexcept { value = expected; });
                                         ~~~^~~~~~~~
1 error generated.
```

the solution is to make `expected` not be `const`.

Reviewed By: yfeldblum

Differential Revision: D14721418

fbshipit-source-id: b65c17414c161b9dee7f269b2e2a22a980766a6c

Summary: It was observed in D14238146 that `ThreadPoolExecutor::numThreads()` is not marked `const`, and it seems that it really should be. This patch marks that function `const` as well as others in this class that seems they should be `const`.

Reviewed By: yfeldblum

Differential Revision: D14681960

fbshipit-source-id: f274b9788ae7e27d6bec22aec2818abeb6441531

Summary: [Folly] `PriorityUnboundedQueueSet`, wrapping `UnboundedQueue`.

Reviewed By: andriigrynenko

Differential Revision: D14719777

fbshipit-source-id: 529ddd8de5879908e36f6fc26e7a091230cb03da

Summary:
```
folly/io/async/test/AsyncTimeoutTest.cpp: In lambda function:
folly/io/async/test/AsyncTimeoutTest.cpp:31:70: internal compiler error: Segmentation fault
       AsyncTimeout::make(manager, [&]() noexcept { value = expected; });
                                                                      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
```

I'm using:

```
 $ /opt/rh/devtoolset-8/root/usr/bin/c++ --version
c++ (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

This has been fixed in gcc 8.3, but the workaround is to explicitly
name the captures as is done in this diff.

Reviewed By: yfeldblum

Differential Revision: D14702587

fbshipit-source-id: 1998ef5de8eb4df520edcc41fdc9cd9547dec824

Summary:
I finally got to the bottom of the weird `-levent` or `event.lib`
linker errors that crop up in the cmake builds.

The issue is that if you have installed a recent libevent it deploys
a cmake CONFIG package that exports just a bare `event` target as the
dep on libevent.  This is unfortunate because it is interpreted as
meaning `-levent` with no library path, which for an installation
of libevent that is not in the default path will result in linker
errors in libraries downstream of folly.

To resolve this, I've given the common `FindLibEvent.cmake` file
(that was derived from the folly library of the same name) a similar
treatment to the recent changes to find glog and taught it how to
locate libevent from a config package and to fall back on a basic
include/library check.

If we find an `event` target then we extract the actual library
path from it and export that.

I've removed folly's and wangle's own FindLibEvent.cmake so that it will pick
up the common library which gets shipit sync'd out to
https://github.com/facebook/folly/blob/master/CMake/FindLibEvent.cmake
and https://github.com/facebook/wangle/blob/master/build/fbcode_builder/CMake/FindLibEvent.cmake

Reviewed By: yfeldblum

Differential Revision: D14702577

fbshipit-source-id: d35d9f741e009dcd77976c0637ba3024a8a4aef3

Summary:
```
folly/experimental/test/FutureDAGTest.cpp:46:7: error: ‘source_node’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       if (it->first != source_node) {
       ^~
cc1plus: all warnings being treated as errors
```

Reviewed By: yfeldblum

Differential Revision: D14702569

fbshipit-source-id: 949ecde007a8d84498c5d87f4a4c2db463ba83a9

Summary:
```
folly/folly/io/test/IOBufCursorTest.cpp:212:3:
folly/folly/io/Cursor.h:411:13: error: ‘void* memcpy(void*, const void
*, size_t)’ forming offset [13, 20] is out of the bounds [0, 12] of object ‘buf’ with type ‘char [12]’ [-Werror=array-bounds]
       memcpy(buf, data(), len);
       ~~~~~~^~~~~~~~~~~~~~~~~~
```

Reviewed By: yfeldblum

Differential Revision: D14702563

fbshipit-source-id: 3697a021d71bccfae9d8833b42a0c25e916b7a78

Summary:
```
folly/experimental/test/LockFreeRingBufferTest.cpp:279:14: error
: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying 1023 bytes from a string of length 1023 [-Werror=stringop-truncation]
       strncpy(data_, data.data_, sizeof(data_) - 1);
       ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

Reviewed By: yfeldblum

Differential Revision: D14702561

fbshipit-source-id: 8f85c758c7afc99eeb1f95920511fb4195eafbbe

Summary:
Making the `co_scoped_lock()` and `co_lock()` operations semi-awatitable forces the caller to provide an executor on which to resume the awaiting coroutine in the case that the lock could not be acquire synchronously.

This improves the safety of folly::coro::Mutex when used from within an InlineTask which does not implicitly wrap all co_await expressions to ensure transitions back to the executor and would otherwise implicitly resume the next lock-acquirer inline inside the call to .unlock().

Reviewed By: andriigrynenko

Differential Revision: D14708636

fbshipit-source-id: bb9cda1a4a6e53978071a7b98ebf9affeef47c7d

Summary:
- Instead of defining a separate `assume_unreachable` wrapper macro for
  support on different compilers, use the one directly from
  `folly/lang/Assume.h` which is spelled `folly::assume_unreachable`.
- Since the `assume_unreachable` wrapper in `FBString.h` was the only
  thing using FBString's wrapper around `always_inline` for various
  compilers as well, we can remove that as well.
Pull Request resolved: https://github.com/facebook/folly/pull/1079

Reviewed By: yfeldblum

Differential Revision: D14605330

Pulled By: Orvid

fbshipit-source-id: ec5529d8913fcec0a7eb03bce006d8fec71d525b

Round up microseconds to nearest millisecond value in the default TimeoutManager::scheduleTimeoutHighRes implementation

Summary:
Round up microseconds to nearest millisecond value in the default TimeoutManager::scheduleTimeoutHighRes implementation

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D14702027

fbshipit-source-id: b0c710c25c1d9b92ebf28e490507eb3dc3f4db31

Summary:
- We have several function objects that define constexpr call operators
  for `operator<`, `operator<=`, etc. These were needed prior to
  C++14 in order for them to be `constexpr`, as vendor implementations did not
  mark them `constexpr`.
- Since Folly requires C++14, callers who are relying on these should
  migrate to `std::less<T>`, and other function objects in the standard
  library, which are now marked constexpr.
Pull Request resolved: https://github.com/facebook/folly/pull/1020

Reviewed By: Orvid

Differential Revision: D14612068

Pulled By: yfeldblum

fbshipit-source-id: 378e148e6fd8e98cfba529c1e1c1a4d8f71dc8a7

Summary:
- Add deduction guide for `fbvector` which is only available if the
  feature test macro for deduction guides is available or if we are on
  MSVC.
Pull Request resolved: https://github.com/facebook/folly/pull/1090

Reviewed By: nbronson

Differential Revision: D14663586

Pulled By: yfeldblum

fbshipit-source-id: b3db8fc6ee3b13b84bb6a4a49d2a1801dc80fd4a

Reviewed By: yfeldblum, philippv, luciang

Differential Revision: D14713196

fbshipit-source-id: 327f2beb064e61e323edfaf9837bc39275bb8d14

Reviewed By: yfeldblum, larabear

Differential Revision: D14692263

fbshipit-source-id: fbdab61363ea83667832dbc56a883d069a1bd597

Summary:
This mirrors what we use when building thrift.
Without this, boost somehow picks a mix of static and shared
libs, but the static linkage doesn't know how to find the libdir
and thus the link fails.

This bubbles up when building folly's tests, which also require
linking with glog.

Reviewed By: yfeldblum

Differential Revision: D14700315

fbshipit-source-id: a331fdb493e7af62b42833b90bd20367778642ea

Summary:
The type is `HANDLE` but is being passed to something that
wants an `int` for a socket/file descriptor, so let's
explicitly translate this into a socket descriptor.

Reviewed By: yfeldblum

Differential Revision: D14680671

fbshipit-source-id: c7b3f6058ca486dbda01b069ec5d67cc2b3ea478

Summary:
this adds the include and library dirs for generated thrift targets;
these are important when those dependencies are not installed into a default
prefix.

Reviewed By: strager

Differential Revision: D14683957

fbshipit-source-id: ed47ffac5c8732810afe77e6947584b7a2f05155

Summary:
When finding a package via its config, we need to
add its include dirs to our list.  Previously we were squeaking
by for this because libevent was installed in either the default
include path or in the same installation prefix as folly.

In the getdeps build environment we have libevent in its own
installation prefix.

The `LibeventConfig.cmake` file from libevent `release-2.1.8-stable` exports
the include dirs via the `LIBEVENT_INCLUDE_DIRS` variable, which is slightly
different from that used by the `folly/public_tld/CMake/FindLibEvent.cmake`
file.

In a later diff I plan to standardize and move the libevent
logic to the common cmake dir.  For now, this unblocks my build.

Reviewed By: strager

Differential Revision: D14680677

fbshipit-source-id: 9f757c84fd145d052925803348008dc2c1abf263

Summary:
changes needed to add pushmi to xplat which is needed to make folly::Executor depend on pushmi.

split from - D12912583

MSVC 15.6.7 (required to keep cuda working) issues:
- __VA_ARGS__ results in a single token on MSVC and not on gcc or clang. I changed the macros to expand the single token so that it is parsed as multiuple tokens again
- some template usage must be placed inside `decltype()` to work with MSVC
- a nested set of macros using __VA_ARGS__ only worked on MSVC and clang when nested twice, but not when nested three times. changed the macros to use explicit parameters.
- gave up on pushmi invoke/invoke_result_t, now uses folly:Invoke instead.
- gave up on property_insert_t, removed usage that was needed for ExecutorTest
- switched many uses of make_receiver/make_sender to full bespoke receiver/sender implementations.
- disabled deduction guides on windows
- disabled apply on windows
- added additional disambiguity for function overloads that MSVC complained were redefinitions (only differed in SFINAE) also reduced to one `operator|` for this reason
- restructured `__property_category_t` and `__properties_t` to reduce MSVC ICE and other issues.
- MSVC did not like `property_set_element<POut, property_category_t<PIn>>` changed to `property_set_element<POut, PCategory>`
- MSVC complained about implicitly deleted destructors for `property_set_insert` explicitly added them..
- MSVC does not like `)::value` sequence added `bool_v`.
- replaced auto with explicit return types in some places.
- added the missing `remove_cvref_t`

In other news:
- added tags.h to minimize Executor dependencies on pushmi
- add `property_set_traits_disable_v` to allow EventBase to disable SequencedExecutor traits specialization
- add support for building without exceptions to the customization points

Reviewed By: ericniebler

Differential Revision: D14686496

fbshipit-source-id: c3f195783fd9a5f77b997498c44d4eebef1afe57

Summary: This diff adds the generator and recursive_generator classes from the cppcoro library to folly.

Reviewed By: lewissbaker

Differential Revision: D13834297

fbshipit-source-id: d27d11c39a35749c168a7c8e53c2819c36083467

Summary:
[Folly] Fix `folly/gen/test/ParallelMapTest.cpp` under MSVC, which does not appear automatically to deduce `{"str"}` as `std::initializer_list<char const*>`.

Breakage in {D14625210}.

Reviewed By: luciang

Differential Revision: D14663535

fbshipit-source-id: 092786236c6589790f234741e52b3fc045bd2b0e

Summary: This allows using blockingWait() with folly::SemiFuture.

Reviewed By: andriigrynenko

Differential Revision: D14658875

fbshipit-source-id: a99505bee3a9947d5fe89760ab495fce5679a0a1

Summary:
- For each F14 container, implement `erase_if(F14Container&, Predicate)` similar to C++20 `erase_if(std::unordered_map&, Predicate)`.
- The semantics of `erase_if` are that it erases all elements in the container which satisfy the given predicate.
Pull Request resolved: https://github.com/facebook/folly/pull/1069

Reviewed By: nbronson

Differential Revision: D14588030

Pulled By: yfeldblum

fbshipit-source-id: 87098804b993e9fb742f3a8feed43453aa99c885

Summary:
When running shell_building, the tree gets littered with __pycache__ files,
hence ignore them.

Reviewed By: wez

Differential Revision: D14664303

fbshipit-source-id: d41837cdfda1ae93c2d9330f00284128b3f7f7d0

Summary:
Extended `folly::coro::Task` to support an lvalue-reference value type.

A `Task<T&>` stores the value internally in a `folly::Try<std::reference_wrapper<T>>` as `folly::Try` does not support reference value types. This means that when you use `co_await task.co_awaitTry()` on a `Task<T&>` that you get back a `folly::Try<std::reference_wrapper<T>>` instead of a `folly::Try<T&>`.

Also added support for using `.co_awaitTry()` on `Task<T>`.
Previously the `.co_awaitTry()` method was only supported on the `TaskWithExecutor<T>` type.

Reviewed By: andriigrynenko

Differential Revision: D14657997

fbshipit-source-id: a168991b5a9c278dcc2387a6ff4fba9e47ccac0d

Summary:
Fix for the HHWheelTimer broken Windows build

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D14642461

fbshipit-source-id: 07292429b1e27eafeb144ab529940aee86dcca6d

Summary: As title.

Reviewed By: yfeldblum

Differential Revision: D14638826

fbshipit-source-id: 1904a1e416f299c2cafc147a3eb15dad325ae240

Summary:
As a step in the plan to migrate LogDevice to using fbcode_builder as
the primary build method, allow LogDevice to build without submodules.
In place of the self compiled modules, the CMake scripts will look in
the system (or provided prefix locations) and use precompiled modules
there. Users can then use fbcode_builder to ensure those required
modules are built and available.

* Use new 'folly_test_util' library rather than referencing sources
directly
Pull Request resolved: https://github.com/facebookincubator/LogDevice/pull/71

Reviewed By: AhmedSoliman

Differential Revision: D14578119

Pulled By: calebmarchent

fbshipit-source-id: 36400d41d3f1906919706d20d0fb53195fec2e63

Summary:
The alloc_hook is invoked on the malloc path. Therefore we should not
allocate on this path.

Reviewed By: yfeldblum

Differential Revision: D14605677

fbshipit-source-id: f95b9ff3e14f65781045d26ce59ec008c113ca81

Summary:
Back out D14608368 "HHWheelTimerBase: use different DEFAULT_TICK_INTERVAL values for milliseconds and microseconds".

The change being backed out breaks the MSVC build; backing it out should restore the MSVC build.

Fixes #1087.

Differential Revision: D14638652

fbshipit-source-id: b06b2934771adeff7a49c54b33da84a5bc973e66

Summary: removed constraints that are no longer valid.

Reviewed By: ericniebler

Differential Revision: D14606943

fbshipit-source-id: bf7acb88e3b6202caaa3e1333d88e5c516eb18e3

Summary:
This switches the output queue from `Output` to `Expected<Output, std::exception_wrapper>`, allowing exceptions to be produced by the predicate. Prior to this change, any exceptions would FATAL, taking down the whole process.

Benchmarks appear unaffected. Memory use will be very similar: Small objects are already padded out to a cache line, so the increase in size will often be zero.

Reviewed By: luciang

Differential Revision: D14625210

fbshipit-source-id: 9bfa1197b7d2285bbc7e42e829beeb3525b3bd44

Summary: Adding note and disabled test for now, will come back to fixing or killing this later.

Reviewed By: yfeldblum

Differential Revision: D14625209

fbshipit-source-id: 6e4f523c02e28fa6080da16485cba68ee78ffc80

Differential Revision:
D13966702

Original commit changeset: 415622dc347d

fbshipit-source-id: 11ff9cac08174cfaefe20e7e4c5e08dc005aaa39