It appears that MSVC treats the specialization of this templated constructor as if it were an overload, causing the selection of constructor to be ambiguous. It only does this if the second template parameter (the EnableIf) if present; otherwise the specialization works correctly.

As a work-around, I refactored the code to avoid specializing the constructor. Instead, we add a static method that encapsulates the differences, which the constructor calls.

Any Own<T> can be converted to Own<void> (or Own<const void>). The main purpose of this is to give someone a way to invoke an object's disposer without them having to know anything about the type.

Fix header validation to match Fetch spec.

Make decodeBase64() report errors

This change modifies decodeBase64() to report errors as required by the WHATWG HTML spec's atob() JavaScript function. Notably, it reports errors for non-whitespace characters outside of the valid base64 character range ([+/0-9A-Za-z=]), and performs sanity checks on padding and input length.

I took care to keep the algorithm single-pass, and to support streaming via multiple calls of base64_decode_block(), though we don't currently expose that functionality.

Base64 decoder: invalid write/read

Autotools installs CMake package config files

Fix input schema file existence check in capnp_generate_cpp

Add missing headers to unbreak the build on FreeBSD/Clang.

capnp_generate_cpp() checks that input schema files exist at configure-time, and reports a fatal error if they don't exist. However, the check prepended the value of CAPNPC_SRC_PREFIX to input file paths, which is the wrong thing to do: the input file paths should be checked as-is if they are absolute paths, and checked relative to the current source directory, NOT the value of capnp's src-prefix flag, if they are relative paths, in order to match the capnp tool's behavior.

It turns out that it's easiest to just unconditionally convert the input file paths to absolute paths, then check the absolute path. The reason is that we can't even pass relative paths to the capnp command, anyway: capnp interprets relative path inputs relative to its working directory, which defaults to the build dir. For consistency with other CMake commands (add_library, add_executable, etc.), it makes most sense if relative file path inputs to capnp_generate_cpp() are interpreted relative to the current source directory. This means that relative path inputs need to be converted to absolute paths before being fed to capnp, which was done right after the faulty existence check.

This commit fixes the issue by modifying the existence check to check the path only after it's been converted to absolute form.

Closes #586.

Extend UnixEventPort with the ability to listen for subprocess exit.

(Later, we should add a nice subprocess API around this, maybe even one that can work on Windows too...)

Adds a new command to super-test.sh:

  ./super-test.sh cmake-package <config>

where <config> is one of:

- autotools-shared
- autotools-static
- cmake-shared
- cmake-static

This command tests the CMake config package files installed by the given build configuration. For now, that test consists of building the samples against an installation of Cap'n Proto.

These variables need to be cache variables or else the user can't override them on the command line (e.g. when building a project against a lite mode installation).

No change in behavior, but the comments needed updating, so I updated them.
Then I noticed a never-true if() case and removed it.

Closes #523.

Copied CMake's bundled AnyNewerVersion template to our local cmake/ directory, and modified both CMake and autotools scripts to configure/install it.

This completes the autotools installation of CMake config files, minus version compatibility checking.

Improve stack trace accuracy by subtracting 1 from each return address.

This should prevent stack traces from spurriously pointing at the line after the one where the call actually happened.

This leaks due to the old compiler bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
http://llvm.org/bugs/show_bug.cgi?id=12286

Previously we only closed immediately after a response finished.

Add TaskSet.onEmpty() to wait until all tasks have completed

Fixes #286.

I intended to do this, like, 4 years ago.