Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically resolved metadata (normalized_metadata) in core #2048

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Dynamically resolved metadata (normalized_metadata) in core #2048

wants to merge 7 commits into from

Commits on Feb 5, 2023

  1. Add lifetime to field::Visit 

    Partially an exercise in "how bad would it be?" This allows the removal
of the unsafety in tracing-log's LogVisitor (see next commit), as well
as generalization of NormalizeEvent to more RecordField containers.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    d4c8525 View commit details
    Browse the repository at this point in the history

  2. Remove unsafety in tracing-log impl 

    Changes like this are the purpose of the previous commit. Now that Visit
has a lifetime parameter, it can be used to extract &str data in a safe
and general manner. While tracing-log is already sound (as indicated by
this safe impl being valid), the lifetime unlocks more generic uses.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    25d2f5e View commit details
    Browse the repository at this point in the history

  3. Uplift trait RecordFields to tracing-core 

    For the time being, it's also been unsealed. There doesn't seem to be a
specific reason to seal it, other than it just existing to generalize
over the provided types, and not being an input generalization.

It can be resealed without issue; however, it being in tracing-core is
necessary for what's coming up.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    cba568c View commit details
    Browse the repository at this point in the history

  4. Remove 'static requirement from Metadata::name 

    Yes, I'm as surprised as you are that this causes 0 issues.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    c001fea View commit details
    Browse the repository at this point in the history

  5. Make more things work with non-'static metadata

    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    6afe420 View commit details
    Browse the repository at this point in the history

  6. Implement dynamic metadata injection 

    Now that places are using non-'static metadata, we can overlay a patched
view of the metadata. Using the strategy seen in tracing-log, we
recognize specifically named metadata/fields and use the values they
provide to create metadata with the resolved runtime values.

Importantly, we also strive to only expose dynamic injection fields when
explicitly asked for. This means that most code can continue on without
knowing that these fields even exist.

Applying these patches does have a cost; notably, things which used to
deal in references like &Metadata or &FieldSet now often use an owned,
patched version instead. These types are primarily bags of references
themselves, and no copying of actual data is involved, but the fact that
the bags of references (which aren't exactly tiny) are copied does have
an impact.

More places which don't have to deal with metadata patching (e.g. the
macro support code) should be audited for what can use the _prenormal
versions of methods.

Additionally, there are likely places where the magic fields leak out
without being explicitly asked for. Ideally, these are all bugs which
can be fixed. There aren't really any tests that effectively check for
this, so new tests will need to be written.

Finaly, there's the question of actually dispatching such a dynamic
event. tracing-log is an example of doing so (but uses touchy, hidden
API to construct the ValueSet) (implemented in the next commit), but a
generally applicable is likely desirable. This will probably take the
shape of dynamic_span! and dynamic_event! macros in tracing proper.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    72ab527 View commit details
    Browse the repository at this point in the history

  7. Implement tracing-log on core dynamic metadata 

    And now we reach the point of this commit series. tracing-log is now
capable of implementing its dynamic metadata resolution on solely
publicly available APIs*, and thus so can anyone else do the same.

*Dispatch still uses #[doc(hidden)] APIs to create the value set.
Figuring out how to best expose is still an open question.
    @CAD97
    CAD97 committed Feb 5, 2023
    Configuration menu
    Copy the full SHA
    6d8bce1 View commit details
    Browse the repository at this point in the history