[metacling] remove redundant 'using namespace std' since std is autoinjected later in TClingUtils

[ferdymercury]

This Pull request:

Changes or fixes:

according to my (limited) tests, interpreter still works without needing to prepend std:: on any class, so this doesn't change behavior

Checklist:

• tested changes locally

[github-actions]

Test Results

    18 files      18 suites   3d 17h 22m 12s ⏱️
 2 666 tests  2 663 ✅ 0 💤 3 ❌
46 270 runs  46 266 ✅ 0 💤 4 ❌

For more details on these failures, see this check.

Results for commit b848e4c.

♻️ This comment has been updated with latest results.

[pcanal]

We should clarify here where the/an other injection of the using namespace std is done. It may (or may not) be that this injection is the logical place to keep (and remove the other instead).

[ferdymercury]

I think/believe in TClingUtils it's not an injection per se of the whole namespace, but rather that it checks if a class is defined within std. Changing it here is straightforward, in the other place I believe much more complicated

[pcanal]

Indeed. The injection per name is the right direction. Please update the commit log to point to where in TClingUtils this is happening.

[hahnjo]

I believe this is far more complicated than just removing the using namespace std, see this PR by Axel from two years ago: #11027

[ferdymercury]

I believe this is far more complicated than just removing the using namespace std, see this PR by Axel from two years ago: #11027

This PR is not aiming at any change in behavior (what Axel tried). It's just "cleaning up the code",. Nothing will change. You will still get the (for some) annoying behavior of having everything within std there in the interpreter. Here in this PR, we just remove a redundant statement.

Note that all tests pass, and the interpreter works as before, which means that this basically like a no-op commit.

[hahnjo]

The explanation is not correct, TClingUtils is not involved in injecting std:: for interpreted code: If you print the code received in cling::Interpreter, you see that it's not qualified. The only reason this still works is that the dictionaries and pcms have using namespace std baked into them, so even after removing the "redundant" declaration in this PR the interpreter gets it as soon as it loads the first pcm, which is basically the first action it does. I think we should not rely on this side effect, the explicit using namespace std that we have right now is better.

[pcanal]

gets it as soon as it loads the first pcm,

Humm ... Did we test this PR with -Druntime_cxxmodules=OFF?

[ferdymercury]

gets it as soon as it loads the first pcm,

Humm ... Did we test this PR with -Druntime_cxxmodules=OFF?

See https://github.com/root-project/root/actions/runs/12164244293/job/33925453332?pr=17175

[hahnjo]

gets it as soon as it loads the first pcm,

Humm ... Did we test this PR with -Druntime_cxxmodules=OFF?

Ok, I wasn't 100% precise: with runtime_cxxmodules=OFF (also default on Windows), you get the using declaration via the pch. The point remains: removing the explicit declaration makes us rely on a side effect of automatic header / pcm / pch loading

[ferdymercury]

I think we should not rely on this side effect, the explicit using namespace std that we have right now is better.

I understand. Feel free to close this PR in that case.

I just thought, if at some point, someone tries to restart with #11027, there was one line less to worry about. Speaking about 11027 and potential ways to slowly going away from global std, from my point of view, it would be nice to have something equivalent to this config variable:

# You can set the variable below to 0 to disable the loading of these
# includes at startup. You can set the variable to 1 (default) to load
# only <iostream>, <string> and <DllImport.h>. You can set it to 2 to
# load in addition <vector> and <utility>.  We strongly recommend setting
# the variable to 2 if your scripts include <vector> and you execute
# your scripts multiple times.
Rint.Includes:      1

So, one could have this interpreter behavior:
Rint.NamespaceStd is 2 by default and calls using namespace std;
If you set it to 1, it just calls using std::string, std::cout, std::endl, std::vector, std::cerr, std::cin, std::array;
If you set it to 0, you need to do things correctly as in a C++ program.

In ROOT 6.42 one could set the default to 1, and in ROOT 9 set the default to 0 ;)

This could be independent on dictionary generation, I guess, that could stay as before with full namespace std statement.