Use weaver for semantic convention codegen

[lquerel]

Changes

This PR marks the first step in the migration to Weaver for semconv code generation. The following changes have been made:

• Utilized Weaver’s new capabilities to simplify code generation as much as possible.
• Moved to SemConv v1.27.0.
• Added a blank line between each declaration for improved readability.
• Attribute notes have been included in comments.
• String examples are now represented using double quotes.
• Boolean examples are represented with true or false, instead of 'True' or 'False'.
• Number examples are represented without single quotes.
• Experimental attributes are now gated behind the semconv_experimental feature.
• Deprecated attributes include a note explaining the reason for deprecation.
• Sorted metric attributes by name.

Note: This PR represents the first step of the plan described here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[lquerel]

We only need to call Weaver once, as the weaver.yaml file specifies what needs to be generated.

[TommyCpp]

Per my understanding this PR only changes the generation tool we use. The end results are still a list of static string right?

[lquerel]

Per my understanding this PR only changes the generation tool we use. The end results are still a list of static string right?

@TommyCpp @cijothomas

Yes, the initial intent was to minimize differences with the existing code generation first and then propose a more advanced integration that removes static strings entirely. However, if the community prefers to move directly to a step where static strings are replaced, such as for attribute declarations like:

pub const HTTP_REQUEST_METHOD: crate::attributes::AttributeKey<HttpRequestMethod> = crate::attributes::AttributeKey::new("http.request.method");

I am happy to update this PR accordingly. This would be straightforward since I already have a proof of concept (POC) for the step 2 described in #2100. Even if we don’t move directly to step 2, which is a fully type-safe API for Rust semconv, we could create an intermediate step (let’s call it step 1.5) where static strings are no longer visible to users or the compiler. I’d appreciate more feedback on this approach.

[lalitb]

The attributes.rs file currently defines semconv constants, which are then re-exported in various other modules (ie trace.rs, metrics.rs, resource.rs). If there aren't any (or too many) shared definitions used across multiple modules, would it make sense to move these constants to their respective modules where they actually belong? The attributes.rs can grow over time as we add more definitions, and add the semconv for logs later, could be difficult to manage even though auto-generated.

I know this has been the existing behavior, but then right time to decide any such change.

[lalitb]

Just to add - this is not a blocker for the PR, something to discuss and plan for subsequent if all agree.

[lalitb]

pub const HTTP_REQUEST_METHOD: crate::attributes::AttributeKey<HttpRequestMethod> = crate::attributes::AttributeKey::new("http.request.method");

@lquerel This looks awesome - in this case it will ensure that HTTP_REQUEST_METHOD will always have valid HTTP verbs. Just thinking in terms of the performance - we will possibly encapsulate these verbs in enum, and then encapsulate the '&static str for http.request.method in a structure AttributeKey. Do you see any performance overhead for (specifically) using them in hot path (as comparison to the existing approach) ?

[lalitb]

@lquerel If all are aligned with the direction -could you address the (nit) review comments (if any) and fix the CI, so that it can proceed for further review/approval?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.0%. Comparing base (0f15d21) to head (9cb825b).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2098   +/-   ##
=====================================
  Coverage   79.0%   79.0%           
=====================================
  Files        121     121           
  Lines      20933   20933           
=====================================
  Hits       16549   16549           
  Misses      4384    4384           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lquerel]

@lalitb I’ve fixed most of the issues, but there are still a few problems related to unescaped markdown links in the semconv registry. cargo doc rejects markdown text like blabla [0,n] blabla. Instead of finding a workaround in the Rust template, I plan to add a new configuration for the comment filter to automatically escape invalid links. See: Issue #374. This should be part of the next release.

[lalitb]

@lalitb I’ve fixed most of the issues, but there are still a few problems related to unescaped markdown links in the semconv registry. cargo doc rejects markdown text like blabla [0,n] blabla. Instead of finding a workaround in the Rust template, I plan to add a new configuration for the comment filter to automatically escape invalid links. See: Issue #374. This should be part of the next release.

Thanks @lquerel. It seems if the CI is breaking, we need to wait for the next release. When is it planned?

[lquerel]

@lalitb We are targeting a new release at the beginning of next week.

[lquerel]

@lalitb @cijothomas Weaver release v0.10.0 fixed the issue with non-escaped invalid links present in the semconv registry that were causing problems with cargo doc. This PR is now ready for final review.

[hdost]

For another review: This binding method seems to be incompatible with SELinux systems.
Is there a particular advantage ?

[lquerel]

Yes, there are advantages. For context, I’ve copied the relevant change log entry below.

(#322, #312,
#319, #318,
#312, #304
by @jsuereth ) Many improvements have been made to the creation of the Weaver Docker image,
which is now scoring an A on the Scout Docker image score.

• Add Weaver docker image to dependabot tracking,
• Add build attestations,
• Stop using root user the docker image,
• Use official docker action to build docker image,
  Update docker to use release build.

[TommyCpp]

LGTM. Thanks for getting start with this

[lalitb]

LGTM to start with. Thanks

[lquerel]

@lalitb @TommyCpp Do you know why the merge into the main is blocked?