1. 11 Jul, 2018 7 commits
    • Marshall Cline's avatar
      deprecate rvalue-qual Future::get(...) · acd11b42
      Marshall Cline authored
      Summary:
      This is part of "the great r-valuification of folly::Future":
      
      * This is something we should do for safety in general.
      * Context: `Future::get(...)` means both `Future::get()` and `Future::get(Duration)`
      * Using lvalue-qualified `Future::get(...)` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
      * Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get(...)`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
      * Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.
      
      Reviewed By: LeeHowes
      
      Differential Revision: D8799081
      
      fbshipit-source-id: 890a221c84ba4847abfaf6e564b0eceb0176fd54
      acd11b42
    • Jack Montgomery's avatar
      Add data() method to folly sorted vector types · c8eeea45
      Jack Montgomery authored
      Summary: Add a data() method to folly::sorted_vector_map and folly::sorted_vector_set which returns a const pointer to the underlying container's data
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8750840
      
      fbshipit-source-id: d361fe21ac741b31b60f551935a3ed8c9549f11a
      c8eeea45
    • Yao Han's avatar
      fix zstd macro (#885) · 16b84942
      Yao Han authored
      Summary:
      detect FOLLY_HAVE_LIBZSTD by true/false
      Pull Request resolved: https://github.com/facebook/folly/pull/885
      
      Reviewed By: terrelln
      
      Differential Revision: D8807276
      
      Pulled By: yfeldblum
      
      fbshipit-source-id: 4372b925a487a31b26cc4c59d7f513639d864f00
      16b84942
    • Sven Over's avatar
      Fast-path destructor · 9ee00d31
      Sven Over authored
      Summary:
      Optimise the destruction of default-constructed and moved-out Function objects. Instead of calling a function pointer that is set to a no-op function, use `nullptr` to signal emptyness of that function pointer and check if it is `nullptr` before invoking.
      This adds additional branching in a few places: not only in the destructor, but also in the move constructor, as well as in the little used `hasAllocatedMemory`. The effect of getting rid of calls to a no-op function pointer should outweigh that.
      
      Reviewed By: djwatson
      
      Differential Revision: D8694003
      
      fbshipit-source-id: 42972805b2ade255cf1dcc98e54985b1524daa73
      9ee00d31
    • Andrii Grynenko's avatar
      Add support for types that implement operator co_await() · 73a507a2
      Andrii Grynenko authored
      Summary: AwaitWrapper was previously only working with types which are Awaitable (i.e. have await_ready()/await_suspend()/await_resume()). This extends it to support types which have operator co_await() implemented.
      
      Reviewed By: lewissbaker
      
      Differential Revision: D8580759
      
      fbshipit-source-id: 980f9c9f34c5a2302badb2ab7c4644883b14aa2c
      73a507a2
    • Lars T. Kyllingstad's avatar
      Prevent bzlib.h from pulling in min and max macros (#884) · 48a252cf
      Lars T. Kyllingstad authored
      Summary:
      This fixes issue #882. Ping terrelln.
      Pull Request resolved: https://github.com/facebook/folly/pull/884
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8794382
      
      Pulled By: terrelln
      
      fbshipit-source-id: 52d8a02991d2be401464ed3cd383a45230ba8ca7
      48a252cf
    • Alfredo Altamirano's avatar
      Assert that we can't construct centroid with weight <= 0 · c33ac44d
      Alfredo Altamirano authored
      Summary:
      We should not be able to create tdigest centroids with weight <= 0.
      Added a debug assert to ensure this.
      
      Differential Revision: D8786969
      
      fbshipit-source-id: 738f2c8d00596365363ea7be88c759da881ab770
      c33ac44d
  2. 10 Jul, 2018 2 commits
    • Dave Watson's avatar
      Use hazptr in RequestContext · c0efc2be
      Dave Watson authored
      Summary:
      Instead of a reader-writer lock in RequestContext data_, use an allocation + hazptr.
      This improves setContext/saveContext perf at the expense of setData.
      
      Differential Revision: D8397670
      
      fbshipit-source-id: 105fd715f1eb09499c88d1a205f019ae01a54f13
      c0efc2be
    • Louis Brandy's avatar
      fix OptionalTest for gcc7 · 6e707da9
      Louis Brandy authored
      Summary: This is horrifying. `std::make_optional` is visible w/o `using` anything, making the use of `make_optional` here ambiguous.
      
      Reviewed By: yfeldblum, elsteveogrande
      
      Differential Revision: D8775609
      
      fbshipit-source-id: 4f1162958909dfab603d2c61473155555a05e9d2
      6e707da9
  3. 09 Jul, 2018 1 commit
    • Wilhelm Bierbaum's avatar
      Add accessor to read connection establishment time-point · 4548dadb
      Wilhelm Bierbaum authored
      Summary:
      In furtherance of advancing connection conditioning in dependent code, the
      time-point which a connection was established can be read through an
      accessor.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8669627
      
      fbshipit-source-id: 156924689354d7a19188f4873009e678a68be64b
      4548dadb
  4. 07 Jul, 2018 1 commit
    • Aaryaman Sagar's avatar
      forward_tuple · 4aeeb1f6
      Aaryaman Sagar authored
      Summary:
      Given a tuple, return a tuple of references whose value categories are derived
      from the value category of the input tuple
      
      Given this, revert to the exact behavior `MQTTChannel` had prior to D8248199.
      
      Reviewed By: mzlee
      
      Differential Revision: D8698755
      
      fbshipit-source-id: c9b68a3f344c6bae25f612a38f5c22be9b7f87bc
      4aeeb1f6
  5. 06 Jul, 2018 1 commit
  6. 05 Jul, 2018 2 commits
    • Marshall Cline's avatar
      use rvalue-qual Future::get(): pass 5 · 964d9f48
      Marshall Cline authored
      Summary:
      This is part of "the great r-valuification of folly::Future":
      
      * This is something we should do for safety in general.
      * Context: `Future::get(...)` means both `Future::get()` and `Future::get(Duration)`
      * Using lvalue-qualified `Future::get(...)` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
      * Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get(...)`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
      * Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.
      
      Reviewed By: djwatson
      
      Differential Revision: D8711357
      
      fbshipit-source-id: 7b6a4119f4427fbc779b1f9e1c0dd44762021894
      964d9f48
    • Mark Santaniello's avatar
      const-qualify some data members · 01920134
      Mark Santaniello authored
      Summary: The `size_` and `upperBound_` fields can be const-qualified.
      
      Reviewed By: ot
      
      Differential Revision: D8734943
      
      fbshipit-source-id: ced8a7c96442772a37bb8be373c71b557598257f
      01920134
  7. 03 Jul, 2018 2 commits
    • Aaryaman Sagar's avatar
      Add missing LockedPtr template constructor · dc4e8512
      Aaryaman Sagar authored
      Summary:
      `LockedPtr`s were not constructible from other `LockedPtr`s with different
      lock policies even if their unlock policies were the same.
      
      Fix that.
      
      Reviewed By: simpkins
      
      Differential Revision: D8722292
      
      fbshipit-source-id: bf17f86bef9ceb8e994a2bd01e66d61dbd51bb12
      dc4e8512
    • Alexander Kindyakov's avatar
      Fix up typo in tryTo<> for enums · 40fb25b3
      Alexander Kindyakov authored
      Summary: This diff fixes the typo in `tryTo` declaration for `enum`s and adds test coverage for enum specialization.
      
      Reviewed By: yfeldblum, shixiao
      
      Differential Revision: D8694574
      
      fbshipit-source-id: d20e34d7d7bae7805cc7c31507cffb292235bdfc
      40fb25b3
  8. 01 Jul, 2018 1 commit
  9. 30 Jun, 2018 3 commits
    • Marshall Cline's avatar
      use rvalue-qual Future::get() · 110882c8
      Marshall Cline authored
      Summary:
      This is part of "the great r-valuification of folly::Future":
      
      * This is something we should do for safety in general.
      * Using lvalue-qualified `Future::get()` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
      * Problems with `Future::get() &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get()`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
      * Reasons `Future::get() &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8704033
      
      fbshipit-source-id: 246f35c6320425e4b76ad11882bf55169988b772
      110882c8
    • Max Katsev's avatar
      alias folly::apply to std::apply on C++17 · 2e7e90e4
      Max Katsev authored
      Summary: Previously this code failed to build due to ambiguity between folly::apply and std::apply
      
      Reviewed By: aary, ot, luciang
      
      Differential Revision: D8705541
      
      fbshipit-source-id: 575c52517792a930d3639b39eba4abc352739d6f
      2e7e90e4
    • Teng Qin's avatar
      Add empty semaphore Macro for non-x86 archs · 9dfd1bda
      Teng Qin authored
      Summary: When people using Static Tracepoint with Semaphore, they'll need to define / declare it. That would cause error on non-supported platforms. This Diff adds empty statement for them.
      
      Reviewed By: myreg
      
      Differential Revision: D8706499
      
      fbshipit-source-id: 2978faf08c451d19e44156308d896e7cac83fcc7
      9dfd1bda
  10. 29 Jun, 2018 7 commits
    • Aaryaman Sagar's avatar
      Add folly::synchronized · 9bcfbd09
      Aaryaman Sagar authored
      Summary:
      Some people said the read-lock-when-const behavior of the `SYNCHRONIZED` macro
      was desirable, so instead of codemodding the `SYNCHRONIZED` macros out of
      existence in favor of `withRLock`, `withWLock` and `withLock`, add a
      generalization of the `SYNCHRONIZED()` macros, so they can be removed in favor
      of this, which has identical behavior while being more general.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8248203
      
      fbshipit-source-id: eb3c1444182e42bea79a377a66606d91a6e517bd
      9bcfbd09
    • Steve O'Brien's avatar
      folly: iterator classes (3/3): IOBuf's custom iterator should use new Iterator detail classes · cd8d5de0
      Steve O'Brien authored
      Summary: IOBuf's custom iterator was changed so that it would no longer need `<boost/iterator_facade.hpp>`.  Change again so that it uses Folly's own (cheap) header file providing roughly the same functionality.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8345072
      
      fbshipit-source-id: bbbfb4373e72444a5e54aeccafd2d316ebdbae63
      cd8d5de0
    • Dave Watson's avatar
      Don't zero-initialize Data · 46dd483d
      Dave Watson authored
      Summary:
      Don't zero-initialize Data.  It's already set in all the constructors we care about,
      and gcc generates pretty aweful code for this.
      
      Reviewed By: ot, spacedentist
      
      Differential Revision: D8678393
      
      fbshipit-source-id: 55a46f3db376ba1f9aa8100f176fd7d8ac18275c
      46dd483d
    • Dave Watson's avatar
      Add move benchmarks · fdf8fee8
      Dave Watson authored
      Summary:
      Adds two benchmarks for small create/move/invoke,
      and both small and large for move, and function ptr move.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8678386
      
      fbshipit-source-id: c78c493587df5d960b603178147d591489c7f519
      fdf8fee8
    • Andrii Grynenko's avatar
      Disable future unwrapping in SemiFuture::defer(Value/Error) · d28b94ab
      Andrii Grynenko authored
      Summary: Future unwrapping in defer is broken for incomplete Futures and SemiFutures with deferred work.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8675535
      
      fbshipit-source-id: 8deff362ea018cf4717354cd973756161c4249aa
      d28b94ab
    • Marshall Cline's avatar
      use rvalue-qual Future::get(): pass 3 · 860b718e
      Marshall Cline authored
      Summary:
      This is part of "the great r-valuification of folly::Future":
      
      * This is something we should do for safety in general.
      * Using lvalue-qualified `Future::get()` has caused some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
      * Problems with `Future::get() &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get()`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
      * Reasons `Future::get() &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.
      
      Codemod steps (where `get(...)` means both `Future::get()` and `Future::get(Duration)`):
      
      * expr.get(...) ==> std::move(expr).get(...)  // if expr is not already an xvalue
      * expr->get(...) ==> std::move(*expr).get(...)
      
      Note: operator precedence of that last step is safe - no need to parenthesize `expr`. Reason: `->` binds more tightly than unary `*`.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8683752
      
      fbshipit-source-id: 593bcd92ca4e11244e0f912cf956538889a2c777
      860b718e
    • Larry-Hu's avatar
      Enable _ENABLE_EXTENDED_ALIGNED_STORAGE to use an extende alignment (#881) · 3dd3467e
      Larry-Hu authored
      Summary:
      We built folly with upcoming Visual Studio 15.8, which failed with the following message:
      error C2338: You've instantiated std::aligned_storage<Len, Align> with an extended alignment (in other words, Align > alignof(max_align_t)). Before VS 2017 15.8, the member type would non-conformingly have an alignment of only alignof(max_align_t). VS 2017 15.8 was fixed to handle this correctly, but the fix inherently changes layout and breaks binary compatibility (only for uses of aligned_storage with extended alignments). Please define either (1) _ENABLE_EXTENDED_ALIGNED_STORAGE to acknowledge that you understand this message and that you actually want a type with an extended alignment, or (2) _DISABLE_EXTENDED_ALIGNED_STORAGE to silence this message and get the old non-conformant behavior.
      
      This enables the `_ENABLE_EXTENDED_ALIGNED_STORAGE`.
      
      Closes https://github.com/facebook/folly/pull/881
      
      Reviewed By: Orvid
      
      Differential Revision: D8689152
      
      Pulled By: yfeldblum
      
      fbshipit-source-id: fada301a163b0b09adc76807dc0e7bd26d9740a9
      3dd3467e
  11. 28 Jun, 2018 6 commits
    • Steve O'Brien's avatar
      folly: iterator classes (2/3): avoid expensive boost iterator headers in `dynamic` · 9dd60503
      Steve O'Brien authored
      Summary:
      In the same vein as some previous diffs: some `boost` headers are expensive.  These `iterator_facade` and related headers (which include -facade.h) are examples of super expensive ones.
      
      `boost/iterator/iterator_adaptor.hpp` in particular shows up as being responsible for appx. 7.5% (avg) of translation units built.
      
      The solution here is: since this bloats `folly/dynamic-inl.h`, in that "private" impl file, I added a workalike class, which is minimal and works well enough to do the job for dynamic's iterators.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8329532
      
      fbshipit-source-id: deaab7b52d110cd29c613d687a6a74c6a42b515d
      9dd60503
    • Steve O'Brien's avatar
      folly: iterator classes (1/3): add minimal facade/adaptor classes + test · 55ec604d
      Steve O'Brien authored
      Summary:
      Iterator helper classes are used in several places around Folly; they're convenient because they take care of some of the details while letting your class provide only a few of the necessary pieces.
      
      Boost has `iterator_facade` and `iterator_adaptor` to help in these cases, but the header for these classes are absurdly expensive to include (their transitive includee tree is quite large).
      
      For this reason, we'll add similar helper classes, with minimal dependencies, under detail.  In subsequent diffs we'll migrate some existing code using these boost classes (or implementing iterators itself) to use these helpers.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8345073
      
      fbshipit-source-id: 3e6656e544349fe228358074de30c89c805e2628
      55ec604d
    • Yedidya Feldblum's avatar
      Fix incorrect copy constructions in ConcurrentHashMap · 3f12b5ad
      Yedidya Feldblum authored
      Summary: [Folly] Fix incorrect copy constructions in `ConcurrentHashMap`, where the `ConstIterator` is move-only but the code attempts to copy it.
      
      Reviewed By: magedm
      
      Differential Revision: D8678003
      
      fbshipit-source-id: 89d47b811fb27ecbbd42cae03a2af13becd0082a
      3f12b5ad
    • Yedidya Feldblum's avatar
      invoke_type members for free- and member-invoke traits containers · f7afb2cc
      Yedidya Feldblum authored
      Summary:
      [Folly] `invoke_type` members for free- and member-invoke traits containers.
      
      Usable as:
      
      ```
      FOLLY_CREATE_FREE_INVOKE_TRAITS(swap_invoke_traits, swap, std);
      // ...
      swap_invoke_traits::invoke_type my_swap;
      my_swap(obj1, obj2);
      
      Reviewed By: aary
      
      Differential Revision: D8670799
      
      fbshipit-source-id: 0c24912721aa20ca9647261e24ed3eb0e340ab20
      f7afb2cc
    • Yedidya Feldblum's avatar
      Refactor apply-invoke traits · 23bb52a4
      Yedidya Feldblum authored
      Summary:
      [Folly] Refactor apply-invoke traits. Can make them smaller by extracting a common denominator and then falling back on the base invoke traits.
      
      Also fixes the build for MSVC2015.
      
      Reviewed By: aary
      
      Differential Revision: D8676590
      
      fbshipit-source-id: f59c7014d3294f3b0978c2fd027cf3a87411f639
      23bb52a4
    • Jon Maltiel Swenson's avatar
      Handle EINVAL errno in MemoryIdler::unmapUnusedStack() · 20d52e14
      Jon Maltiel Swenson authored
      Summary:
      If `MemoryIdler` is used with threads that are backed by huge pages, the
      `madvise(..., MADV_DONTNEED)` calls will fail with an `EINVAL`. Prior to this
      diff, this would lead to an assertion failure. Now, if `EINVAL` is returned, we
      warn the user, as `MemoryIdler` may not be able to function as expected.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8669399
      
      fbshipit-source-id: f97ea7549deffdbf283b3516b9e8feafe18a036c
      20d52e14
  12. 27 Jun, 2018 7 commits
    • Yedidya Feldblum's avatar
      Simpler free-invoke traits · aeeb73ac
      Yedidya Feldblum authored
      Summary: [Folly] Simpler free-invoke traits. Only supports one namespace housing a base definition. For the typical case of `swap`, with a base definition in `namespace std`, this works.
      
      Reviewed By: aary
      
      Differential Revision: D8666221
      
      fbshipit-source-id: abfd302e430ad7151c119e98a706201265d302d3
      aeeb73ac
    • Dan Melnic's avatar
      Make the pthread key a singleton · a65e66ab
      Dan Melnic authored
      Summary: Make the pthread key a singleton
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8663589
      
      fbshipit-source-id: 1e0c328104bd8c3d3c689dc4955a185336e74276
      a65e66ab
    • Phil Willoughby's avatar
      don't throw in noexcept function · 1e274dc6
      Phil Willoughby authored
      Summary:
      `throw` within a `noexcept` function triggers a compiler warning on the latest clang in C++17 mode.
      
      As the behavior of uncaught `throw` within a `noexcept` context is to terminate the program, do so explicitly.
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8651221
      
      fbshipit-source-id: 004c4c132ad9b5b873a92cf2710b9d1ebe4e705b
      1e274dc6
    • Aaryaman Sagar's avatar
      Cut LockedGuardPtr and its variants · 78cd0ec8
      Aaryaman Sagar authored
      Summary:
      The compiler will likely remove the branch on destruction because
      it's never used
      
      Reviewed By: yfeldblum
      
      Differential Revision: D8651868
      
      fbshipit-source-id: ef16b9d11569f72aa0fa89cb6aa2450a58d783e7
      78cd0ec8
    • Nathan Bronson's avatar
      fix elision of iter advance in F14 erase with unused return value · 4029908d
      Nathan Bronson authored
      Summary:
      D8395569 added a prefetch instruction as part of iterator advance
      for F14Value and F14Node maps.  This caused the work to advance the
      iterator returned by erase to no longer be recognized as dead code by the
      GCC optimizer.  This diff separates out advance() and advanceLikelyDead()
      methods, avoiding prefetch in the latter case.
      
      Reviewed By: shixiao
      
      Differential Revision: D8656038
      
      fbshipit-source-id: 86cecf40e8622f815d34a98709b90d6ef73dd618
      4029908d
    • Nathan Bronson's avatar
      handle allocators with only explicit rebinding constructor · a99ccb8b
      Nathan Bronson authored
      Summary:
      D8586283 added an implicit conversion from allocator_type to a
      uint8_t-rebound allocator, but allocators might provide only an explicit
      rebinding constructor.  This diff makes F14 use the explicit form.
      It also adds a binary that when debugged (in a buck build environment)
      is useful for evaluating code size.
      
      Reviewed By: shixiao
      
      Differential Revision: D8655289
      
      fbshipit-source-id: c977edb041ce2056f3ce23c52a7f8464a6b9f1bd
      a99ccb8b
    • Andrew Gallagher's avatar
      folly: fix some missing standard library includes · 91a001f0
      Andrew Gallagher authored
      Reviewed By: igorsugak
      
      Differential Revision: D8653359
      
      fbshipit-source-id: 5bb33792aa96a0ed7f88a672100955f366c568da
      91a001f0