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

Jump to bottom

Problem with "using namespace std" in generated dictionary files #6343

Closed
cgleggett opened this issue Sep 11, 2020 · 2 comments · Fixed by #6852 or #7655
Closed

Problem with "using namespace std" in generated dictionary files #6343

cgleggett opened this issue Sep 11, 2020 · 2 comments · Fixed by #6852 or #7655
Assignees
@Axel-Naumann
Labels
affects:6.22 bug in:Dictionaries priority:critical
Projects
Fixed in 6.24/00 Fixed in 6.26/00
Milestone
6.24/00

Comments

@cgleggett
Copy link

cgleggett commented Sep 11, 2020 •
edited

In the autogenerated dictionary sources I see

// Since CINT ignores the std namespace, we need to do so in this file.
namespace std {} using namespace std;

(this is from 6.14.08. 6.22.02 has a slightly different comment of The generated code does not explicitly qualifies STL entities (sic), but still does the using...)

This is placed very early on, even before the include of the header files passed as arguments.

Unfortunately, this causes problems, specifically when one of those header files pulls in Kokkos core headers, and there's a name clash with rank which is a free function in the kokkos namespace, and std::rank.

/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:30: error: return type specified for deduction guide
 KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
                              ^
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1895:42: error: decl-specifier in declaration of deduction guide
 template <typename D, class... P>
                                          ^       
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1895:32: error: decl-specifier in declaration of deduction guide
 template <typename D, class... P>
                                ^~       
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:30: error: 'signed' or 'unsigned' invalid for '__dguide_rank'
 KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
                              ^
/opt/kokkos/cuda/3.2-shlib/include/Kokkos_View.hpp:1896:1: error: deduction guide for 'std::rank< <template-parameter-1-1> >' must have trailing return type
 KOKKOS_INLINE_FUNCTION constexpr unsigned rank(const View<D, P...>& V) {
 ^~~~
/bld4/opt/gcc/8.4.0/include/c++/8.4.0/type_traits:1251:8: note: 'template<class> struct std::rank' declared here
     struct rank
        ^~~~

Is there any way to make the using namespace appear AFTER the include of the user header files instead of before?

If I manually edit the generated file, and move the using namespace to after the includes, it compiles fine.

FWIW, the actual compilation is done with nvcc 11, and c++17.

thanks, Charles.
@Axel-Naumann Axel-Naumann self-assigned this Sep 14, 2020
@hageboeck hageboeck added this to Critical in Triage Sep 18, 2020
@Axel-Naumann Axel-Naumann added this to the 6.24/00 milestone Nov 20, 2020
Axel-Naumann added a commit to Axel-Naumann/root that referenced this issue Nov 20, 2020
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes root-project#6343:
1ed2c51 
`using namespace std` can have detrimental side effects on user headers.
Assume that they are compilable, given that they will be included in the
dictionary source. Given this, move the using directive after the inclusion
of user headers, to not affect them, but only the generated dictionary
source code (CINT-compatible std-less type names etc).
@Axel-Naumann Axel-Naumann linked a pull request Nov 20, 2020 that will close this issue
[rootcling] Emit using std after user headers, fixes #6343: #6852
Merged
Axel-Naumann added a commit to Axel-Naumann/root that referenced this issue Nov 24, 2020
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes root-project#6343:
9dcbaed 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).
Axel-Naumann added a commit to Axel-Naumann/root that referenced this issue Mar 18, 2021
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes root-project#6343:
ced3342 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).
Axel-Naumann added a commit to Axel-Naumann/root that referenced this issue Mar 22, 2021
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes root-project#6343:
6d2bb44 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).
Axel-Naumann added a commit that referenced this issue Mar 22, 2021
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes #6343:
df98daa 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).
Axel-Naumann added a commit to Axel-Naumann/root that referenced this issue Mar 23, 2021
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes root-project#6343:
0b30a65 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).

(cherry picked from commit df98daa)
Axel-Naumann added a commit that referenced this issue Mar 29, 2021
@Axel-Naumann
[rootcling] Emit using std after user headers, fixes #6343:
2e9e420 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).

(cherry picked from commit df98daa)
@Axel-Naumann Axel-Naumann reopened this Mar 29, 2021
@Axel-Naumann Axel-Naumann linked a pull request Mar 29, 2021 that will close this issue
[v624][rootcling] Emit using std after user headers, fixes #6343: #7655
Merged
@Axel-Naumann Axel-Naumann added this to Issues in Fixed in 6.24/00 via automation Mar 29, 2021
@Axel-Naumann Axel-Naumann added this to Issues in Fixed in 6.26/00 via automation Mar 29, 2021
@Axel-Naumann
Copy link
Member

Fixed in master and the upcoming v6.24/00. Is this enough for you or do you also need this in v6.22/10?

nicknagi pushed a commit to nicknagi/root that referenced this issue Mar 30, 2021
@Axel-Naumann @nicknagi
[rootcling] Emit using std after user headers, fixes root-project#6343:
7b304c5 
`using namespace std` can have detrimental side effects on user headers.
For non-ACLiC invocations, assume that user headers are compilable. In
those casesm move the using directive after the inclusion of user headers,
to not affect them, but only the generated dictionary source code
(which is using CINT-compatible std-less type names etc).
@cgleggett
Copy link
Author

6.24/00 is fine. thanks Axel!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Axel-Naumann Axel-Naumann

Labels
affects:6.22 bug in:Dictionaries priority:critical
Projects
No open projects
Fixed in 6.24/00
Issues
Fixed in 6.26/00
Issues
Milestone
6.24/00
2 participants
@Axel-Naumann @cgleggett