The bazel -> cmake generator is currently not capable of handling
separate included generated cmake files making use of common C/C++
dependencies.
To work around this limitation, a single generated cmake is now in
place. Long-term, we should either:
* make the cmake generator handle common dependencies gracefully, or
* make the cmake generation aspect travel up `pkg_` rules `srcs`
attributes
so to avoid having to list the targets to be generated in the top-level
`BUILD` file.
Other things fixed:
* removed some warning spam about redefined `BAZEL_CURRENT_REPOSITORY`
* fixed the final link step, that was failing because `libswiftCore.so`
was not being linked.
The recommended option is Markdown diagnostics, and we have already migrated everything to emit them. The empty help link we're currently emitting everywhere is a bug.
Specifically, this adds custom formatters using `path::operator string()` and `error_code::message()` and dereferences a (non-empty) optional. `fmtlib` provides formatters for these standard library types in `fmt/std.h`, but that file also requires RTTI (which we disable) for `std::exception` so we can't use it without either patching `fmtlib` (which they're open to: https://github.com/fmtlib/fmt/issues/3170) or enabling RTTI (which will require some consideration).
This required a bit of an overhaul of the original integration of
JSON diagnostics into binlog.
The problem is that it is quite hard to add a kind of metadata to
binlog entries without changing its code. Another problem is that when
wanting to avoid double evaluation of logging macro arguments one
cannot really add a separate "diagnose" step easily.
The proposed solution consists in two things:
* hook into a binlog plumbing function by providing a better overload
resolution match, which happens after logging macro expansion,
bypassing the problem of double evaluation
* in that hook, produce the diagnostic directly, without waiting to
reconstruct the diagnostics entry from the binlog serialized entry.
This allows to forgo the weird category to diagnostic mapping, and now a
diagnostics emission simply happens when a diagnostic source is given
as the first argument after the log format string. A flavour of
diganostics sources with locations is then added with the same
mechanism, allowing to write something like
```cpp
LOG_ERROR("[{}] ouch!", internalError.withLocation("foo.swift", 32));
```
This reverts commit 0d9dcb161f.
This turns out to introduce a subtle bug related to destruction order
between `Log::instance()` and the `Logger` instances.
