Mark functions and variables as inline to avoid "TU-local entity exposure" issue

[isaevil]

Description

This PR fixes ODR violations when inline functions either invoke static functions or use static global variables (fixed by using inline variables since C++17). This also resolve the issue with exposure of TU-local entities when building C++20 modules and using TBB API in exported declarations.

Fixes # - issue number(s) if exists

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No - the only public global variable that was static is tbb::flow::no_priority which is constant predefined value. This change shouldn't affect TUs that used this constant in regular way (i.e. passing this value as parameter to nodes' constructors).
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[vossmjp]

Someone (maybe me) should write an RFC about the direction for _flow_graph_trace_impl.h. Flow Graph Analyzer, which is the only/primary user of _flow_graph_trace_impl.h, was deprecated as a tool within Advisor in Intel(R) Advisor 2024.1 and then removed in Intel(R) Advisor 2025.0. So we need to decide what to do with this support. For this release, we can fix the uses of static but ultimately we might remove much of this code.

[aleksei-fedotov]

As far as I understand, this changes the linkage for all of the internal stuff. Previously, they had internal linkage, and now they start to have external and therefore visible to other TU so that the linker can deduplicate definitions and use only one of them.

What I don't understand is whether the external linkage makes these things visible outside the library, like the exported functions. Essentially, introducing new entry points. It seems it does, isn't it?
And then, I guess, the .def files and/or default visibility settings conveniently cover this part by hiding them from the out-of-library world.

Is my understanding correct?

[isaevil]

As far as I understand, this changes the linkage for all of the internal stuff. Previously, they had internal linkage, and now they start to have external and therefore visible to other TU so that the linker can deduplicate definitions and use only one of them.

What I don't understand is whether the external linkage makes these things visible outside the library, like the exported functions. Essentially, introducing new entry points. It seems it does, isn't it? And then, I guess, the .def files and/or default visibility settings conveniently cover this part by hiding them from the out-of-library world.

Is my understanding correct?

Yes, since we hide all symbols not listed in .def files by default, functions/constants will still remain local in library.

[aleksei-fedotov]

Looks good to me.