- 11 Jul, 2018 7 commits
-
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
- 10 Jul, 2018 2 commits
-
-
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
-
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
-
- 09 Jul, 2018 1 commit
-
-
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
-
- 07 Jul, 2018 1 commit
-
-
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
-
- 06 Jul, 2018 1 commit
-
-
Wenting Zhao authored
Summary: timeout dosen't take effect for add() of ThreadManager Reviewed By: andriigrynenko Differential Revision: D8674748 fbshipit-source-id: a0336fb78182ad432b2d8e5beb61f785e59f0fdd
-
- 05 Jul, 2018 2 commits
-
-
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
-
Mark Santaniello authored
Summary: The `size_` and `upperBound_` fields can be const-qualified. Reviewed By: ot Differential Revision: D8734943 fbshipit-source-id: ced8a7c96442772a37bb8be373c71b557598257f
-
- 03 Jul, 2018 2 commits
-
-
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
-
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
-
- 01 Jul, 2018 1 commit
-
-
Andrii Grynenko authored
Summary: This fixes a race in AwaitWrapper, but also makes it easier for compiler to perform the heap elision optimisation. Differential Revision: D8701500 fbshipit-source-id: 86efd5089ac7fdf32f64b3d84fcbfbefb9824365
-
- 30 Jun, 2018 3 commits
-
-
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
-
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
-
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
-
- 29 Jun, 2018 7 commits
-
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
- 28 Jun, 2018 6 commits
-
-
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
-
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
-
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
-
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
-
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
-
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
-
- 27 Jun, 2018 7 commits
-
-
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
-
Dan Melnic authored
Summary: Make the pthread key a singleton Reviewed By: yfeldblum Differential Revision: D8663589 fbshipit-source-id: 1e0c328104bd8c3d3c689dc4955a185336e74276
-
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
-
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
-
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
-
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
-
Andrew Gallagher authored
Reviewed By: igorsugak Differential Revision: D8653359 fbshipit-source-id: 5bb33792aa96a0ed7f88a672100955f366c568da
-