- 09 Jun, 2017 1 commit
-
-
Neal Gompa authored
The Autotools and CMake builds are almost the same, except for the libraries not being generated as versioned libraries in CMake. Fixing this lets Linux CMake builds be on the same level as Autotools ones.
-
- 05 Jun, 2017 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
- 29 May, 2017 3 commits
-
-
Harris Hancock authored
-
Harris Hancock authored
Closes #479. If T is a template instantiation and `List<T, kind<T>()>` is the return or parameter type of a function (notably get, set, init, adopt, and disown functions) defined out-of-line from its definition, MSVC fails to match the definition with its declaration. This seems to be another consequence of poor expression SFINAE / constexpr support. An easy workaround is to avoid using kind<T>() and instead manually instantiate Kind_<T>, as in lite mode. When I converted Kind_<T> to use VoidSfinae, I had thought this solved the problem, but clearly there are still edge cases.
-
Harris Hancock authored
-
- 26 May, 2017 1 commit
-
-
Kenton Varda authored
This work-around had been removed in 75c7aaee. However, it turns out that many Debian Jessie systems still use 4.9.2 (not 4.9.4, which is fixed). I've changed the #if to more specifically target 4.9.x, which should cover all affected versions (in addition to some fixed versions).
-
- 23 May, 2017 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
- 22 May, 2017 2 commits
-
-
Kenton Varda authored
This conversion would end up including the NUL terminator in the array, which is almost never what you want. We can perhaps re-enable this in the future and have it automatically remove the NUL terminator, but we should do at least one release with it disabled to catch anyone who might be affected by the change in behavior.
-
Kenton Varda authored
People see files named "md5" and get worried about security issues, even though we're using it only as a *non-cryptographic* PRNG. So, I renamed the files to type-id.*, encapsulated the code better to make clear that it's only used to generate type IDs, and added comments clarifying that we're not expecting it to be collision-proof. Fixes #482.
-
- 21 May, 2017 1 commit
-
-
Kenton Varda authored
Using the `Provide` message's question ID to identify the provision doesn't work because the question ID could be freed up and re-assigned before the recipient tries to receive the provision.
-
- 19 May, 2017 3 commits
-
-
David Lamparter authored
-
David Lamparter authored
-
David Lamparter authored
-
- 03 May, 2017 1 commit
-
-
Ian Denhardt authored
At some point isCallersFault was marked as obsolete, but the description of abort still referenced it, suggesting particular usage. This patch removes said references. Since `git-diff` does *such* a good job with prose: This just removes the two parentheticals and re-flows the paragraph.
-
- 30 Apr, 2017 1 commit
-
-
David Renshaw authored
-
- 29 Apr, 2017 4 commits
-
-
Harris Hancock authored
Projects which use Cap'n Proto require C++11, because they must be able to compile our headers. Old gcc defaults to C++98, forcing users to manually specify the -std=gnu++11 flag in their CMake projects. CMake 3.1 introduced the target_compile_features command which removes this necessity by automatically communicating the C++ standard level requirement to client projects. Specifically, if target `kj` requires a C++11 feature publicly, then all targets which link to `kj` will also require that C++11 feature, and get the -std=gnu++11 flag for free. If that target is a library, such as `kj-async`, and `kj-async` links publicly to `kj`, the requirement is also transitive to all targets which link to `kj-async`. Note that CMake's default behavior is to request compiler-specific extensions, such as those provided by the -std=gnu++11 flag. You must specifically opt out of these extensions. I'm not aware of any way to propagate this nuance in CMake, but added a check to at least prevent users from compiling Cap'n Proto without extensions. With this change, the c++/samples/CMakeLists.txt will build with MinGW with no change beyond requiring a later version of CMake.
-
Kenton Varda authored
This reverts commit f836a5fc.
-
Kenton Varda authored
-
Kenton Varda authored
-
- 28 Apr, 2017 6 commits
-
-
Kenton Varda authored
On Linux this cuts 56% off the run time of the fuzz test (aka 2.28x speedup). On Windows this makes it practical to run the fuzz test at all -- previously it was wayyyyyyy too slow.
-
Kenton Varda authored
-
Kenton Varda authored
-
Harris Hancock authored
This option was only useful when MSVC couldn't build the capnp command line tools, so let's back it out.
-
Harris Hancock authored
The previous solution used hard-coded paths which would have had to be special-cased for multi-configuration generators such as Visual Studio, which put binaries in individual Debug, Release, etc. directories.
-
Harris Hancock authored
MSVC as of VS2015 does not initialize the vtable pointers of constexpr objects, causing nullptr dereferences at runtime. To solve this, we can just convert them to regular const variables with internal (static) linkage. The internal linkage bit is important: as long as they are invisible outside their respective translation units, we do not risk the static initialization order fiasco. If we ever need to reference them outside their translation units, we would need to hide them behind functions (like HeapArrayDisposer::instance()) to keep things safe.
-
- 26 Apr, 2017 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Apparently the test has accidentally been using the installed capnp all along.
-
- 25 Apr, 2017 7 commits
-
-
Kenton Varda authored
Specifically, consider: capnp::BuilderFor<capnp::DynamicStruct> capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema) Note that `BuilderFor` is a "template using" directive which expands into something more complicated. GCC mangles the symbol as: _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xcl4kindIS6_EEEE4TypeENS_12StructSchemaE Which `c++filt` decodes as: capnp::BuilderFor_<capnp::DynamicStruct, (kind<capnp::DynamicStruct>)()>::Type capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema) Note that `BuilderFor_<...>::Type` here ends up being a typedef for `DynamicStruct::Builder`. It seems weird to me that the symbol name would not substitute this typedef. Clang, meanwhile, mangles the symbol as: _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xclgssr5capnpE4kindIS6_EEEE4TypeENS_12StructSchemaE Which `c++filt` does not seem to be able to demangle at all. But, it looks like `capnp::kind` is in there, suggesting that, again, the typedef wasn't substituted. I don't know who is right, but if we inline the whole thing, the problem goes away.
-
Kenton Varda authored
Fixes #251
-
Kenton Varda authored
Fixes #336
-
Kenton Varda authored
Fixes #363.
-
Kenton Varda authored
Fixes #403
-
Kenton Varda authored
Fixes #405
-
Kenton Varda authored
Fixes #456
-
- 24 Apr, 2017 2 commits
-
-
David Renshaw authored
-
Kenton Varda authored
-
- 22 Apr, 2017 2 commits
-
-
David Renshaw authored
-
David Renshaw authored
-