facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-10 16:57:49 +03:00
Code Issues Projects Releases Wiki Activity
A Scalable, User-Friendly Source Control System.
1,413 Commits 24 Branches 62 Tags 324 MiB
Rust 45.1%
Python 20.7%
C++ 10.5%
Perl 9.1%
TypeScript 7.4%
Other 7%
7ca1134ee4
Go to file
Marshall Cline 7ca1134ee4 use rvalue-qual Future::onError(): pass 3 
Summary:
This is part of "the great r-valuification of folly::Future":

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).onError(...)` instead of `f.onError(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Codemod changes:

* expr.onError(...) ==> std::move(expr).onError(...)  // if expr is not already an xvalue
* expr->onError(...) ==> std::move(*expr).onError(...)

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: D9505757

fbshipit-source-id: de666f3a877313526d10f5d3569a1bbb2203f066
2018-08-24 23:08:32 -07:00
CMake Rename generated client source file 2018-08-07 17:22:13 -07:00
common add more APIs to common/stats stubs 2018-07-27 14:36:42 -07:00
eden use rvalue-qual Future::onError(): pass 3 2018-08-24 23:08:32 -07:00
.gitignore ignore the entire external/ directory 2018-04-27 13:05:53 -07:00
CMakeLists.txt do not require SELinux in GitHub build 2018-07-27 13:22:57 -07:00
CONTRIBUTING.md Initial commit 2016-05-12 14:09:13 -07:00
getdeps.py enable rocksdb snappy support in GitHub build 2018-07-27 14:36:42 -07:00
LICENSE Initial commit 2016-05-12 14:09:13 -07:00
PATENTS Initial commit 2016-05-12 14:09:13 -07:00
README.md Fix a typo in Eden's README.md. 2016-05-13 09:32:03 -07:00

README.md

Eden

Eden is a project with several components, the most prominent of which is a virtual filesystem built using FUSE.

Caveat Emptor

Eden is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects, such as Buck, Watchman, and Nuclide.

The version that we provide on GitHub does not build yet.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

  • The reinterpretations of build macros in DEFS.
  • A process for including third-party dependencies (presumably via Git submodules) and wiring up the external_deps argument in the build macros to point to them.
  • Providing the toolchain needed to power the [undocumented] thrift_library() rule in Buck.

The goal is to get Eden building on both Linux and OS X, though Linux support is expected to come first.