Summary: It's called `.native()` for a reason, and returns a `wstring` on windows, so call `string()` instead.

Reviewed By: yfeldblum

Differential Revision: D4229254

fbshipit-source-id: d5f9658b41f45fd719ca3e878a2e61c9dce24f10

Summary:
Derived from `sdt.h` in [[ https://sourceware.org/systemtap/ | SystemTap ]]
Performed changes and clean-ups including:
- Get rid of the `sdt-config.h`.
- Get rid of "Running in Assembler" code.
- Replace the `DTRACE_PROBE_1, ... DTRACE_PROBE_N` Macro family with a single Macro using the "count Macro arguments" trick
- Get rid of argument signed-ness calculation. A **lot** of painful code were there only for this, and it has no real usage except for displaying purposes.
- Re-structure the helper methods (Macros) so that the logic of the code is a bit more readable.
- Add some comments so that it would be easier for users and future developers to understand what this header file is actually doing.
- Update license banner.

Reviewed By: meyering

Differential Revision: D3792966

fbshipit-source-id: 564a1011f7946d30be78191f334e072d94fa264e

Summary:
Even when linked against the dynamic runtime.
In truth, the old way was far cleaner, but we do need to be able to close the file descriptors as there is a hard global limit set by the CRT when it's compiled of 8k file descriptors.
This closes it by applying a flag that prevents calls to `CloseHandle` from actually closing the handle, then we call `_close` to get the file descriptor itself closed, then we can call `_closesocket` to close the socket and handle.
This is complicated by the fact that attempting to close a handle that you've marked as being prevented from being closed will trigger an SEH exception, but only if you have a debugger attached. That means that, for anything closing sockets to be debuggable, we have to handle that exception (as a no-op) and then get to have fun trying to get `STATUS_HANDLE_NOT_CLOSABLE`, which for some absurd reason, is only defined as part of the driver developer kit's headers. Some fun ensued where VS was nice enough to point out that the bcrypt headers also defines `NTSTATUS`, and doesn't require building as a driver to use it. For that reason we borrow its definition of `NTSTATUS` rather than declaring it ourselves.
We also have to prevent the main windows headers from defining the base SEH exceptions, because those will be redefined by `ntstatus.h` otherwise :(

Reviewed By: yfeldblum

Differential Revision: D4222625

fbshipit-source-id: 6ed7e91b7a735b5506eb189e452983cd8cace34b

Summary: The helper exists because MSVC is a pain in this regard, so use it.

Reviewed By: yfeldblum

Differential Revision: D4224037

fbshipit-source-id: 6c6415877785f13ea91618a3042f2470dccd08c1

Summary:
There was a recent change in boost compatibility that changed fibers internals and thus broke this script.
This diff fixes gdb script to properly print stack trace for fibers.

Reviewed By: yfeldblum

Differential Revision: D4214575

fbshipit-source-id: 4bf69e9b297c7539a2b2b71093998c30d6a2d81c

Summary: Ubuntu 16.10 has a package for zstd 0.5.1 which is too old to be used by folly.  With this change autoconf will check that one of the newer functions is present, disable zstd if not.

Reviewed By: Orvid, philippv

Differential Revision: D4219964

fbshipit-source-id: 1e64dfb62f81f7e61b097cb7d4fd3810da476625

Summary: Because Windows disagrees with everything else about how to specify that you want the wildcard address. It's done with an empty string on Windows, but `nullptr` everywhere else.

Reviewed By: yfeldblum

Differential Revision: D4216970

fbshipit-source-id: b5dc136946d9677a96be3252e44d383a6abca800

Summary: The good news is that it's cleaner than it was to start with.

Reviewed By: yfeldblum

Differential Revision: D4215323

fbshipit-source-id: 6758092f1e76f60b360753026bb7716737a51304

Summary: It's the only test in the file that is dependent on Subprocess, which is currently unsupported under MSVC.

Reviewed By: yfeldblum

Differential Revision: D4214812

fbshipit-source-id: 9dcd9763b51d037e0c452f79f134df286a11e718

Summary: Anything calling folly::init() will not link with open source build

Reviewed By: yfeldblum

Differential Revision: D4214296

fbshipit-source-id: 636ed5ae8ad36a323054efaad96d3756f1b7b9d0

Summary:
Then it's time to get food.
The bug report linked in the comment has more details.

Reviewed By: yfeldblum

Differential Revision: D4209389

fbshipit-source-id: 87e72691555992bdf964b0ded1173daadcedffa4

Summary: Because, to the best of my knowledge, MSVC is quite right to claim it doesn't know which `dynamic` everyone keeps referring to. Is it `folly::dynamic` or `::dynamic`?

Reviewed By: yfeldblum

Differential Revision: D4209535

fbshipit-source-id: 63322a8f960954e1a63fe5c9a4a5d9395c7827d9

Summary: It was including gtest directly, making MSVC unhappy.

Reviewed By: yfeldblum

Differential Revision: D4208744

fbshipit-source-id: 7100058f3c9fde38744888c99e927c610f11d013

Summary: Windows automatically closes the underlying file descriptor when you call fclose, however fclose is not a function that can be easily overriden in the portability layer, so choose to just not call `close` on Windows instead.

Reviewed By: yfeldblum

Differential Revision: D4190524

fbshipit-source-id: a68edccd04e63f89c178ade584fa7192845773f8

Summary:
VS 2017 RC brings with it fixes for some things and unfortunately, a few known regressions in expression SFINAE. In this case, alias templates with dependent `decltype()` calls are broken, so switch to a templated struct instead.
It's the very last issue mentioned in: https://blogs.msdn.microsoft.com/vcblog/2016/06/07/expression-sfinae-improvements-in-vs-2015-update-3/

Reviewed By: yfeldblum

Differential Revision: D4199676

fbshipit-source-id: 9ce157cc891182509a30b000de1b509063387244

Summary: The value of std::is_copy_assignable<folly::Synchronized<T>>::value is incorrect when T isn't copy assignable. As a result, it isn't possible to use SFINAE to properly select a function when the base type is a folly::Synchronized. This diff selectively deletes the copy constructor and copy assignment operator when the underlying type T isn't copyable. This is most useful in the case of folly::Synchronized<std::unique_ptr<...>>

Reviewed By: yfeldblum

Differential Revision: D4203081

fbshipit-source-id: 1e811f9e52db26c23b1c6f1907bac9e2854ddb9d

Summary: Because, as the comment says, MSVC fails miserably at this, producing errors at compile time.

Reviewed By: yfeldblum

Differential Revision: D4207544

fbshipit-source-id: d9a11b72877d22d3d3fe2e2c862d99601ab21431

Summary:
Expose folly::symbolizer::dumpStackTrace() for use with
custom signal handlers.

Reviewed By: luciang

Differential Revision: D4174004

fbshipit-source-id: 510b77edef652f3e9d10f0acfb4998b64a15fad5

Summary:
Print a message to `std::cerr` when the current program is about to call `std::terminate` because a `folly::ScopeGuard` callback threw an exception. This goes to `std::terminate` in the (common) cases when the `ScopeGuard` destructor is `noexcept`

This gives the user a small clue as to what just happened, since the default diagnostics for this on some platforms do not help at all.

Reviewed By: nbronson

Differential Revision: D4061096

fbshipit-source-id: c3b534d4a36b095e08e46f375251b6fd416ccd68

Summary:
doNotOptimizeAway's "X" input operand constraint is interpreted
more loosely by gcc than by clang, resulting in surprising behavior
for doNotOptimizeAway(*ptr) and a difference in behavior between gcc
and clang benchmarks.  clang also is more aggressive about placing an
input operand into a register even when the constraint would allow it to
be in memory, so an "r,m" constraint has a similar problem.  This diff
changes the input constraint so that register-sized values must actually
be copied into a register, which makes the behavior more intuitive and
more consistent across platforms.

Reviewed By: davidtgoldblatt

Differential Revision: D4199767

fbshipit-source-id: aa56a7b11cb3229b95da87295f0dfc38476959d2

Summary:
[Folly] Fix Build: `folly` with `-Wmissing-braces`.

Construction of `std::array` with list-initialization for the contained C array requires double braces, per the standard.

Compilers accept it with single braces, but will reject it when `-Wmissing-braces` is passed.

Reviewed By: igorsugak, meyering

Differential Revision: D4202629

fbshipit-source-id: e5b87a655e7f25e6cddb931dda28b172c768f227

Summary: These macros apply to both C and C++.

Reviewed By: yfeldblum

Differential Revision: D4199905

fbshipit-source-id: 8dc22959d0a6349c6c76415d1a38eda52cab83a5

Summary:
Using already-available lookup table instead of a bunch of branching, this improves read throughput from ~750MB/s to 2.1GB/s in benchmarks.

```
before:        (time)   (rate)
BM_unhexlify   1.39ns  719.26M
after:
BM_unhexlify 470.59ps    2.13G
```

Reviewed By: philippv

Differential Revision: D4201352

fbshipit-source-id: 8393e066c45c402ccb8b537fdb25417e8e6a9511

Summary:
The standard says this shouldn't be done, but GCC, Clang, and MSVC all do, at least, MSVC does if you don't pass the `/permissive-` switch to disable this non-compliant lookup.
This just qualifies it with `this->` which solves the problem.

MSVC plans to eventually (some time after the 2017 release) enable `/permissive-` by default, so let's start compiling with it now.

Reviewed By: yfeldblum

Differential Revision: D4200725

fbshipit-source-id: 8545c6bcda9ba6006733c15f668805cb1260517a

Summary: This was relying on it being transitively included by system headers, which isn't the case under MSVC.

Reviewed By: yfeldblum

Differential Revision: D4199882

fbshipit-source-id: c25dc1e86687e19851923a1a660a91bcf63f0e6d

Summary: Because MSVC doesn't let you access it without capturing it from within a lambda otherwise.

Reviewed By: yfeldblum

Differential Revision: D4199867

fbshipit-source-id: 7b829b2cc373edbebe3498901fa323c89a211818

Summary:
it seems second is the boolean that we need to compare.
Closes https://github.com/facebook/folly/pull/518

Differential Revision: D4197096

Pulled By: yfeldblum

fbshipit-source-id: 71987dafac0ddbdb7817b55732619edbe9aed81b

Summary:
Replace deprecated functions with their functionally equivalent counterparts.

See https://github.com/lz4/lz4/blob/dev/lib/lz4.c#L1405 and https://github.com/lz4/lz4/blob/dev/lib/lz4hc.c#L634

Reviewed By: Cyan4973

Differential Revision: D4194834

fbshipit-source-id: aa4f934c46fe764fcec8ea29221e3882da2b5cdf

Summary:
This implements a view onto an EventBase, which can keep track of all tasks created through it and join them on destruction. Multiple VirtualEventBases can be backed by the same EventBase. This can be useful to have the same IO thread/thread-pool be shared between multiple libraries, allowing them to each have it's own VirtualEventBase and control its lifetime.

Since VirtualEventBase also supports LoopKeepAlive and onDestruction functionality, it can be easily integrated with FiberManagerMap.

Reviewed By: yfeldblum

Differential Revision: D4158719

fbshipit-source-id: 7df964f36e5276e2b5665fd8394ea2e187aa298c

Summary: #accept2ship

Reviewed By: yfeldblum

Differential Revision: D4192095

fbshipit-source-id: eb0cad875bcc24d1c87a99890c51aea31f7024c9

Summary: And also use it in a couple of tests, so that they can be compiled on Windows, where `pthread_t` is a struct rather than a pointer or integer.

Reviewed By: yfeldblum

Differential Revision: D4191560

fbshipit-source-id: 5bcf0a2952109b2a9bc5220c4640d42e2cdf8977

Summary:
Including `iostream` in a header causes anything that uses this header to gain
an extra static initializer for an `std::ios_base::Init` object.
If there are N translation units in a library that use the header, that's N
more static initializers that need to run.

Reviewed By: yfeldblum

Differential Revision: D4191798

fbshipit-source-id: 65b47401b9177177999cff65a47ac8dffa0e0546

Summary:
Because MSVC doesn't like it when you attempt to explicitly capture a c-style array in a lambda capture list.
See: https://developercommunity.visualstudio.com/content/problem/2444/cannot-explicitly-capture-c-style-array-in-lambda.html

Reviewed By: yfeldblum

Differential Revision: D4191400

fbshipit-source-id: 305f8086c29f079ccf2c322f20da6393235bc76d

Summary: Closes https://github.com/facebook/folly/pull/517

Reviewed By: igorsugak

Differential Revision: D4191764

Pulled By: Orvid

fbshipit-source-id: 5ab921bd0df0b9dbaca46cdf9ecdeea9ecda6f5a

Summary: Because it won't compile due to an MSVC bug. See the link in the comment for more info.

Reviewed By: yfeldblum

Differential Revision: D4191233

fbshipit-source-id: 523deebe12379ff56934a4259b601d4ab677b9b6

Summary:
Constructing an empty FBVector by length results in a call to
memset with a null destination, which is undefined behavior.  This diff
fixes it.

Reviewed By: luciang, meyering, Gownta

Differential Revision: D4191612

fbshipit-source-id: 3dcc091396fc33ac2230bd2d90906325131b0a3b

Summary:
Because, as discussed in past diffs, MSVC currently requires them to be static in order to resolve them from within the scope of a lambda when they aren't captured.
The only one that actually needs to be marked as `static` is `numReps`, but I like consistency, so I marked them all as static.

Reviewed By: yfeldblum

Differential Revision: D4191610

fbshipit-source-id: 7246170f30551d2079b4373eefbf3d02aab6dfa9

Summary: Because it had better be numeric or something is very wrong.

Reviewed By: yfeldblum

Differential Revision: D4190568

fbshipit-source-id: 52a5ebfcedb545201191fc48f66a4419eee8f748

Reviewed By: philippv

Differential Revision: D4184097

fbshipit-source-id: 2f1f82b845528fea4667af612c92c348f8d9ec25

Summary: MSVC currently has a bug that causes it to incorrectly resolve it to `std::queue`: https://developercommunity.visualstudio.com/content/problem/2342/c-failure-to-resolve-instance-member-in-lambda-con.html

Reviewed By: lbrandy

Differential Revision: D4187256

fbshipit-source-id: 207eafa339f7255ae881d8ab80f4847222c3b8c9