* Fix annotations in year 2038
Fixes#3050
* Ensure 32-bit systems work better after 2038
Without this patch, their 32-bit signed long int could overflow.
This patch was done while working on reproducible builds for openSUSE.
This uses CMake to build a simple Rust library (in `src/tc/rust`) that
just re-exports everything from the `taskchampion-lib` crate.
The C++ wrappers then wrap this into C++ objects with proper lifecycle
maintenance, in the `tc` namespace.
The C++ wrappers are incomplete, and missing methods are tagged with
"TODO". These will be added as needed.
When adding a new task, the current task is empty, so there is no
context in which to evaluate DOM references. #2683 will address this in
a more robust fashion.
It's possible to call getDOM without a contextual task. Previously,
this was done by referencing a "dummy" task which necessitated a way to
distinguish such dummy tasks. This switches to using a pointer and
treating the NULL value as meaning there is no context.
Note that this cannot use `std::optional<&Task>`, as optional does not
support reference types.
Each tag is stored as `tag_<tagname>: x`. The `x` is required because
empty attributes are treated as nonexistent.
For compatibility, the `tags` attribute is updated in sync with the
per-tag attributes. This compatibility support may be dropped in later
versions.
Note that synchronization _updates_ use JSON format, which does not
change with this patch, and thus no compatibility issues exist. The
synchronization _initialization_, however, uses FF4, meaning that a
sync server initialized from a version of `task` with this patch will
contain `tag_<tagname>` attributes, which will look like orphaned UDAs
to older versions. However, as updates to tasks are synchronized via
the sync server, the updates will not contain these attributes and they
will show as "deleted" in the `task info` display on the older version.
Aside from the noise in the `task info` output, this is harmless.
Attribute names are often words from natural language (such as start,
end or entry). The ColumnTypeString supports resolving DOM references,
such that task commands like 'task add proj:3.proj' work.
However, the current implementation of the ColumnTypeString::modify
only looks at the first token to determine whether the input is a DOM
reference or not. This mischaracterizes inputs like 'task add
"description:start something"', where the first token of the attribute
value looks like a DOM reference (the 'start' attribute), but is in
fact, a part of larger string.
Since all DOM references are single tokens, only interpret the input as
a possible DOM reference if and only if one token was found.
Closes#1908.
