- 24 Jul, 2015 1 commit
-
-
Nick Terrell authored
Summary: This diff is not yet complete, I want to see the contbuild before I change the functions that return references to member functions. It is unsafe to return a pointer when the dynamic object is a rvalue, because if the pointer escapes the expression after the object is destroyed, we go into segfault / undefined behavior land. I have deleted these overloads. The amount of valid code that is now disallowed is minimal. The only valid case I can think of is returing a pointer and passing it to a function in the same expression that does not save the pointer. However, this case is also dangerous, because if the function you pass it to decides to save the pointer for later, we are in trouble, e.g. save_ptr(dynamic("str").c_str()) Since there are simple workarounds (naming the object), I think that is a small price to pay for the greatly increased safety. The next step is to overload all members that return a reference to a member to move the member out if the dynamic is a rvalue: const dynamic& at(dynamic const&) const&; dynamic& at(dynamic const&) &; dynamic at(dynamic const&) &&; // Move out I also need to go over the code more carefully to make sure that nothing went wrong. Reviewed By: @marcinpe Differential Revision: D2257914
-
- 23 Jul, 2015 2 commits
-
-
Tudor Bosman authored
Summary: Many command line apps are of the form "program [--global_options] command [--command_options] args..." Make writing such things less painful. +jdelong because smcc Reviewed By: @meyering Differential Revision: D2217248
-
Tudor Bosman authored
Summary: GFlags is useful for global program options. boost::program_options makes it easier to write command-line utilities. They don't, unfortunately, play very nicely with each other. Add a addGFlags() function to convert all GFlags to boost::program_options options; you can then use boost::program_options::parse_command_line() to parse all arguments, GFlags or not. Also add a helper function to make parsing nested command lines easier. Reviewed By: @fugalh Differential Revision: D2215285
-
- 22 Jul, 2015 4 commits
-
-
Nathan Bronson authored
Summary: SharedMutex purposely allows the inline reader count to underflow in some situations while preserving proper locking behavior (the inline reader count is only trusted if all deferred locks have been applied), but there was an additional way that this could occur that wasn't documented or allowed by the asserts. The effect was a false positive assert in rare conditions or the possibility of losing track of a deferred lock slot. This diff fixes both the over-aggressive assert and the potential loss of the shared slot. If the assert didn't fire for you then this diff won't change the correctness of your program. Reviewed By: @yfeldblum Differential Revision: D2269018
-
Tudor Bosman authored
Summary: Because I didn't want to write it again. Reviewed By: @yfeldblum Differential Revision: D2217246
-
Ondrej Lehecka authored
Summary: fixing compiler errors when compiling with Wunused-parameter Reviewed By: @yfeldblum Differential Revision: D2267014
-
Hannes Roth authored
Summary: Thanks @peijinz for finding this. Reviewed By: @peijinz Differential Revision: D2268532
-
- 21 Jul, 2015 7 commits
-
-
Nick Terrell authored
Summary: `get_ptr()` checks if the index is past the end of the array, but it doesn't check if it is less than 0, while `at()` does. Reviewed By: @yfeldblum Differential Revision: D2258548
-
Hannes Roth authored
Summary: A timeout now raises `TimedOut()` on the current Future. Reviewed By: @fugalh Differential Revision: D2261559
-
Hans Fugal authored
Summary: This fixes github issue https://github.com/facebook/folly/issues/243 I don't understand why this is broken on osx, but the solution is to just `#include <thread>` in the header instead of trying to forward declare `std::thread`. Reviewed By: @yfeldblum Differential Revision: D2255026
-
Ondrej Lehecka authored
Summary: fixing C++ compiler warnings for the -Wunused-parameter warning switch on. This is fixing only the header files, not the library cpp files. Reviewed By: @yfeldblum Differential Revision: D2259957
-
Viswanath Sivakumar authored
Summary: This is causing a log of spew in proxygen logs Reviewed By: @afrind Differential Revision: D2262006
-
Tom Jackson authored
Summary: Forces consumers to handle the empty sequence case instead of cumbersome exceptions. Reviewed By: @jrichey, @yfeldblum Differential Revision: D2219505
-
Yedidya Feldblum authored
Summary: [Folly] Fix a namespace nit in folly/futures/Future.cpp. As soon as someone introduces a namespace `folly::futures::detail` this will blow up. Fix it so it won't blow up when that happens. Reviewed By: @hannesr Differential Revision: D2258799
-
- 20 Jul, 2015 11 commits
-
-
Sara Golemon authored
-
Brian Watling authored
Summary: Allow access to a FiberManager's currently running fiber Reviewed By: @alikhtarov, @andriigrynenko Differential Revision: D2257201
-
Nick Terrell authored
Summary: `folly::Optional` returns the stored value by reference when the object is an rvalue. This causes three issues: * If the user calls `value()` on an rvalue `Optional`, and assigns the result to a new variable, the copy constructor gets called, instead of the move constructor. This causes the added test `value_move` to not compile. * If the user calls `value()` on an rvalue `Optional`, and assigns the result to a const lvalue reference, they might expect the lifetime to be extended when it isn't. See the added test `value_life_extention`. * Assigning the results of `value()` on an rvalue `Optional` to a mutable lvalue reference compiled in the old code, when it shouldn't, because that is always a dangling reference as far as I can tell. I'm not sure how strict `folly` is with compatibility, but I believe the breakage would be minimal, and any code that gets broken probably deserves it. I'm not exactly sure who I should add as a reviewer, so hopefully herald has got my back. Reviewed By: @yfeldblum Differential Revision: D2249548
-
Steve O'Brien authored
Summary: The creator thread ID is saved to indicate the singleton is already being built (to help detect dependency cycles). However if the creation function throws an error, that thread ID persists, and then if the same thread tries again to build the singleton it will be falsely detected as a dependency cycle. This clears that state in the case of failure. Reviewed By: @chipturner Differential Revision: D2256441
-
Hannes Roth authored
Summary: This reverts commit 956351018a495af89575526536af7e7c0bb285aa. Reviewed By: @labrams Differential Revision: D2258219
-
Steve O'Brien authored
Summary: In nested loop, loop condition is incorrect. Fixed var (should be `ii` not `i`) Reviewed By: @pgriess Differential Revision: D2255702
-
Tom Jackson authored
Summary: I'm upgrading assertions to throws, since these are fatal in all circumstances. If something is explicitly `Optional`, it makes sense to fail loudly if it is misused in this manner. Reviewed By: @yfeldblum Differential Revision: D2247612
-
James Sedgwick authored
Summary: to unbreak OSS wangle tests build Reviewed By: @bugok Differential Revision: D2240264
-
Tudor Bosman authored
Summary: What it says on the tin. Reviewed By: @fugalh Differential Revision: D2230390
-
Pavlo Kushnir authored
Summary: guard pages may make debugging more painful. For example, in some cases they increased "perf" initialization time. Reviewed By: @alikhtarov Differential Revision: D2247188
-
Hannes Roth authored
Summary: I figured it out. This works. The two extra futures are a small overhead (just two pointers). The `Core`s are allocated anyway, so this is pretty much optimal. A timeout now raises on the current Future, and a fulfilled promise cancels the timeout Future. Reviewed By: @yfeldblum Differential Revision: D2232463
-
- 15 Jul, 2015 8 commits
-
-
Sara Golemon authored
Summary: As the comment says, we can ignore errors in setting the size. So it stands to reason we can ignore setting the size as well. Reviewed By: @yfeldblum Differential Revision: D2242882
-
Sophia Wang authored
Summary: There are more use cases that the Destruction/Guard pattern can be used than current DelayedDestruction provides. This diff makes the pattern more general (remove self destruct) and lets DelayedDestruction derive from that. The functionalities of DelayedDestruction is kept unchanged. I leave destroy(), Destructor class, and destroyPending_ in DelayedDestruction since they are not required by our CallbackGuard in proxygen. I add a shouldDestruct() function to allow customized conditions on when to call destructor. I haven't made destroyNow() a std::function since I only need it to be set at instatiation time. If there is any other use case that needs destroyNow() to be a std::function, I can do that as well. Reviewed By: @afrind Differential Revision: D2202575
-
Joe Richey authored
Summary: Before we didn't do anything at all with the ::infinite value for our generators, now all the sources operators and sinks are properly notated. The one signifcant change regarding what is allowed concerns 'cycle' which now (when called with no arguments) always produces an infinite generator. This is fine for all but the weirdest of generators fed into cycle. Reviewed By: @ddrcoder Differential Revision: D2240328
-
Joe Richey authored
Summary: When adding in the 'filter()' default behavior, I considered adding in similar behavior for 'any' and 'all'. However, we had 'any' with no funciton call basically check if anything was present, not testing a predicate. This can create a confusing senario, so I removed this behavior from 'any' and added in the 'isEmpty' and 'notEmpty' sinks. Now the calls 'any()' and 'all()' (called with parens, so old uses won't compile) check for truthy values simlar to 'filter()'. I also added some unit tests and changed 'static const' objects to 'constexpr'. Reviewed By: @ddrcoder Differential Revision: D2234637
-
Andrii Grynenko authored
Summary: Integrating RequestContext into fibers library. RequestContext is saved for every task, when that task is created. If RequestContext is overriden when a task is being run (within fiber, in runInMainContext, within function passed to await call) the new context will continue to be used for the task. Reviewed By: @alikhtarov Differential Revision: D2240152
-
Lucian Grijincu authored
Reviewed By: @philippv Differential Revision: D2240628
-
Yedidya Feldblum authored
Summary: [Folly] Fix Build: folly/io/async/test/ScopedEventBasedThreadTest.cpp Failure with latest clang: folly/io/async/test/ScopedEventBaseThreadTest.cpp:72:8: error: explicitly moving variable of type 'folly::ScopedEventBaseThread' to itself [-Werror,-Wself-move] sebt = std::move(sebt); Reviewed By: @markisaa Differential Revision: D2238762
-
Yedidya Feldblum authored
Summary: [Folly] File ctor should take StringPiece. This way we can use it with `std::string` and `folly::fbstring` a touch more easily. Reviewed By: @luciang Differential Revision: D2235870
-
- 13 Jul, 2015 4 commits
-
-
Sara Golemon authored
-
Andrii Grynenko authored
Reviewed By: @chipturner Differential Revision: D2235232
-
Kjell Schubert authored
Summary: This is only a simple #include file split, no functional change was made. SmallLocks.h provides 2 classes: MicroSpinLock and PicoSpinLock, with the latter not being available on 32bit platforms. There are several classes in folly that included SmallLocks.h but only needed MicroSpinLock, these also refused to compile on 32bit, e.g. folly/futures/Future.h. Now these compile fine. Reviewed By: @yfeldblum Differential Revision: D2234263
-
Yedidya Feldblum authored
Summary: [Folly] An has_member_type macro. Reviewed By: @juchem Differential Revision: D2229775
-
- 09 Jul, 2015 3 commits
-
-
Joe Richey authored
Summary: After discussion with Tom about frozen files, we noticed that the use case of filtering out somthing that looks like false (0, nullptr, folly::none) is unnecessarily tedious. So folly::gen::filter now filters by the value of the item by default. Reviewed By: @ddrcoder Differential Revision: D2220582
-
Subodh Iyengar authored
Summary: Add mocks for the new isBufferMovable methods. Reviewed By: @yfeldblum Differential Revision: D2222642
-
Yedidya Feldblum authored
Summary: [Folly] ThreadedExecutor. It's an Executor that runs functions each in its own thread. Kind of simple. Suitable for a few types of strange cases. Reviewed By: @hannesr Differential Revision: D2226211
-