Add noexcept/const qualifier at missing places for Trace API.

[lalitb]

Changes

This allows these methods to be used in the functions which are noexcept without explicit exception handling.

We may have to look at similar changes for log/metrics api separately.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #1374 (a9b505d) into main (5458dde) will increase coverage by 0.01%.
The diff coverage is 96.88%.

@@            Coverage Diff             @@
##             main    #1374      +/-   ##
==========================================
+ Coverage   85.35%   85.36%   +0.01%     
==========================================
  Files         151      151              
  Lines        4361     4362       +1     
==========================================
+ Hits         3722     3723       +1     
  Misses        639      639              

Impacted Files	Coverage Δ
api/include/opentelemetry/trace/tracer_provider.h	100.00% <ø> (ø)
api/include/opentelemetry/trace/noop.h	86.21% <50.00%> (ø)
api/include/opentelemetry/baggage/baggage.h	97.33% <100.00%> (+0.03%)	⬆️
...pi/include/opentelemetry/baggage/baggage_context.h	100.00% <100.00%> (ø)
api/include/opentelemetry/common/kv_properties.h	98.96% <100.00%> (ø)
api/include/opentelemetry/common/string_util.h	100.00% <100.00%> (ø)
api/include/opentelemetry/context/context.h	100.00% <100.00%> (ø)
...pi/include/opentelemetry/context/runtime_context.h	97.60% <100.00%> (ø)
api/include/opentelemetry/trace/context.h	100.00% <100.00%> (ø)
api/include/opentelemetry/trace/default_span.h	13.34% <100.00%> (ø)
... and 2 more

[ThomsonTan]

Just curious whether adding noexcept could break existing API usage in any case.

[lalitb]

Just curious whether adding noexcept could break existing API usage in any case.

I don't think it should break API/ABI compatibility. Though reverse ( removing noexcept) can break things.

[reyang]

Just curious whether adding noexcept could break existing API usage in any case.

I don't think it should break API/ABI compatibility. Though reverse ( removing noexcept) can break things.

IIRC noexcept is not included in the mangled name but not sure if it's compiler specific or covered by the standard spec. From semantic standpoint +1 with what @lalitb said.

[lalitb]

IIRC noexcept is not included in the mangled name but not sure if it's compiler specific or covered by the standard spec.

Validated it across gcc, clang and msvc and it generates the similar mangled name for both these prototypes:

void foo1()
void foo2() noexcept

msvc: https://gcc.godbolt.org/z/sb7szM8xd
gcc: https://gcc.godbolt.org/z/17fovvd37
clang: https://gcc.godbolt.org/z/Pebcox9xz