The sqlite3 source code has a lot of implicit fallthroughs in case
statements. They are documented with comments but even though gcc
provides options to use these comments to suppress the warnings, that's
not always reliable. For instance, it may fail if an #ifdef follows the
comment or if the comment is within a block scope used for a case.
With gcc version '(Ubuntu 7.3.0-16ubuntu3) 7.3.0' I get warnings similar
to the below:
../../../vendor/sqlite/src/sqlite3.c: In function ‘sqlite3_db_status’:
../../../vendor/sqlite/src/sqlite3.c:20251:10: error: this statement may fall through [-Werror=implicit-fallthrough=]
op = SQLITE_DBSTATUS_CACHE_WRITE+1;
So disable the implicit falltrhough warnings for that library. Note that
-Wno-error=implicit-fallthrough is not used to keep the build silent
since this is vendor library.
- added missing linker flags for Sanitize configuration type
- changed mason's download to use cmake's built-in support instead of directly calling curl
Based on patch from @lbud (Lauren Budorick).
Give `HeatmapColorPropertyValue` a more generic name,
since the same value type will be used for both `heatmap-color`
and `line-gradient` properties.
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
