* Declare in corresponding header files and dissolve main.h
Apply include-what-you-use
* Remove further unncessary includes
* Incorporate review comment
* Do not declare static functions and variables in header
* Adapt test
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
The code for parsing epoch timestamps when displaying tasks only
supports values between year 1980 and 9999. Previous to this change, it
was possible to set e.g., the due timestamp to a value outside of these
limits, which would make it impossible to later on show the task.
With this change, we only allow setting values within the same limits
used by the code for displaying tasks.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's
`Task` type more cleanly. It also introduces the idea of gathering lists
of operations and "committing" them to a replica.
A consequence of this change is that TaskChampion no longer
automatically maintains dependency information, so Taskwarrior must do
so, with its `TDB2::dependency_sync` method. This method does a very
similar thing to what TaskChampion had been doing, so this is a shift of
responsibility but not a major performance difference.
Cxx is .. not great. It is missing a lot of useful things that make a
general-purpose bridge impractical:
- no support for trait objects
- no support for `Option<T>` (https://github.com/dtolnay/cxx/issues/87)
- no support for `Vec<Box<..>>`
As a result, some creativity is required in writing the bridge, for
example returning a `Vec<OptionTaskData>` from `all_task_data` to allow
individual `TaskData` values to be "taken" from the vector.
That said, Cxx is the current state-of-the-art, and does a good job of
ensuring memory safety, at the cost of some slightly awkward APIs.
Subsequent work can remove the "TDB2" layer and allow commands and other
parts of Taskwarrior to interface directly with the `Replica`.
* move taskchampion-lib to src/tc/lib, remove the rest
* update references to taskchampion
* Use a top-level Cargo.toml so everything is consistent
* apply comments from ryneeverett
* 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.
