googletest uses std::tr1 which will be deprecated in VS 2017

[StephanTLavavej]

In VS 2017's second toolset update, I'm going to deprecate the std::tr1 namespace (with the [[deprecated]] attribute, emitting compiler warnings) in both the C++14 and C++17 modes. This will cause googletest's use of std::tr1 to emit warnings (breaking builds under /WX).

While I will provide an escape-hatch macro to silence the deprecation warnings, googletest should migrate away from using std::tr1, as it will be removed in the future (eventually completely, with no escape hatches).

This is almost identical to #872 and #1036 but not quite. Those issues are observing how I removed std::tr1 by default in C++17 mode. This issue is about how std::tr1 will be deprecated even in the default C++14 mode, affecting all users.

[KindDragon]

PR #811 should fix this. But for some reason, no one wants to merge it

[BillyDonahue]

We're just working on some high-priority internal stuff right now. This should be ok to merge. Sorry for the neglect.

…

On Wed, Jun 7, 2017 at 6:28 PM, Arkady Shapkin ***@***.***> wrote: PR #811 <#811> should fix this. But for some reason, no one wants to merge it — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AINnRJYWSOj4c-tlaVKnNRBR_dcy2V5Oks5sByQigaJpZM4NyNdw> .

[mropert]

Seconding this, today I'm forced to pass -DGTEST_LANG_CXX11=1 to my gtest build to work with VS 2017 in /std mode.

[BillyDonahue]

Stephan, "googletest's use of std::tr1" where? Those uses should be hidden behind platform-version #ifdef directives, please let me know if there's a place this is being done incorrectly.

IIRC, PR #811 is doing more than this, dealing with CMake etc, so it's hard to know it's the right answer for the simpler tr1 migration.

[StephanTLavavej]

In MSVC's STL, I'm deprecating the namespace by saying namespace std { namespace [[deprecated("MESSAGE")]] tr1 { /* stuff */ } }. As a result, anything that includes an STL header and that mentions std::tr1 will trigger the warning. This will happen even if googletest tries to be clever and says namespace std { namespace tr1 { /* using-declarations or other stuff */ } }, because I have already marked tr1 as deprecated and further openings of the namespace can't un-deprecate it. (Technically, you'll still get away with reopening the namespace like that, but any attempted use of std::tr1::tuple will warn.)

I think

googletest/googletest/include/gtest/internal/gtest-port.h

Line 660 in 8c7f93f

&& !GTEST_OS_QNX && !defined(_LIBCPP_VERSION)) || _MSC_VER >= 1600

is an example of problematic logic - it tries to use std::tr1 even for modern MSVC.

[KindDragon]

IIRC, PR #811 is doing more than this, dealing with CMake etc, so it's hard to know it's the right answer for the simpler tr1 migration.

JFYI, PR #811 (#1218) doesn't change cmake files

[BeErikk]

Sorry, as a user I still get this error in the Visual Studio 2017 IDE compile. I have a fresh gtest git clone. Using the compiler outside of the IDE works fine to compile gtest though. Unsure what the default setting is. To get gtest to compile you need to apply -std:c++14

[KindDragon]

Can be closed. PR #1218 fixed this

[andyleejordan]

Just FYI, if you're a user consuming gtest 1.8.0 and cannot/don't want to patch it, when invoking CMake for it you can use:

-DCMAKE_CXX_FLAGS=/D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING

To keep building. It's a work-around.

[msemegen]

Still same problem on master build...

[TzuChieh]

Same here... building from a fresh git clone using VS2017 triggers hundreds of errors about std::tr1.

[Ozaq]

Will this trigger a new release? I now have the problem that our organization requires 'official' releases for third party software but we also keep all software (including Visual studio) up to date

[gennadiycivil]

TR1 tuple and our own implementation of tuple has been removed from master

[rleigh-codelibre]

@gennadiycivil Is there any ETA on a release containing this fix?

[gennadiycivil]

Roger , could you please explain what 'fix', not clear Thanks

…

On Sat, Nov 10, 2018, 12:05 Roger Leigh ***@***.*** wrote: @gennadiycivil <https://github.com/gennadiycivil> Is there any ETA on a release containing this fix? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJSMqzP35NTISo4XT__TZeGrg8bQ-Byks5utwdBgaJpZM4NyNdw> .

[rleigh-codelibre]

@gennadiycivil I meant that now the tr1 stuff is dropped from master, is there an ETA for a public release containing these fixes? It's a bit of a blocker for C++17 development. While I'm currently working with custom builds off master, having this in e.g. vcpkg and other common distributions would be highly desirable.

[gennadiycivil]

The next release will be as specified Post 1.8.x - work to improve/cleanup/pay technical debt. When this work is completed there will be a 1.9.x tagged release". We don't have dates just yet. Thanks G

…

On Mon, Nov 12, 2018 at 8:57 AM Roger Leigh ***@***.***> wrote: @gennadiycivil <https://github.com/gennadiycivil> I meant that now the tr1 stuff is dropped from master, is there an ETA for a public release containing these fixes? It's a bit of a blocker for C++17 development. While I'm currently working with custom builds off master, having this in e.g. *vcpkg* and other common distributions would be highly desirable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJSMpB6cK3pyWoi2gP5WDr8EJPUfjWaks5uuX5UgaJpZM4NyNdw> .

[thomthom]

It appear that using 1.8.1 there is no longer any need for _SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING.
(Just an FYI. To me this wasn't clear based on the notes in the GitHub release or from this issue.)

[denysvitali]

Or, if you're using googletest 1.8.3 from NuGet, remember to read the package details: you need to add GTEST_LANG_CXX11 to the compiler definitions, so that your code can be compiled w/ VC++17.
I just lost an hour trying to understand why it didn't compile. 🤷‍♂️

[damian123]

This issue still remains. Can we roll the fix out please?
Since many projects depends on gtest it is very annoying for these to maintain workarounds.
Thanks!

[gennadiycivil]

@damian123 not clear what 'issue' you are referring to and what exactly ' roll the fix' mean - could you please explain.

[gennadiycivil]

@gennadiycivil I meant that now the tr1 stuff is dropped from master, is there an ETA for a public release containing these fixes? It's a bit of a blocker for C++17 development. While I'm currently working with custom builds off master, having this in e.g. vcpkg and other common distributions would be highly desirable.

There is a number of assumtions in this question that I think should be addressed:

1. "Public release" : I am not aware of the terminology. Yes at some point we will cut a branch of the code and will call it 1.9.x . This is it, that is the extent of the "release". As to "public" I would like to help but simiply not aware what this means, everything in this GitHub repo is already public.

You may just as well pick a point in the master and use it.

2. " having this in e.g. vcpkg and other common distributions would be highly desirable." - if this is your development process, of course, this would make sense. However this is not in googletest hands. While we welcome "someone else" to pakage googletest if they so desire, we don't' explicitly do it ourselves.

Hope this helps.

In additon, this is a reply to "closed" GitHub issue, and there is a very high chance I will never see it because of the filters. It may be better to open a new issue if we need to communicate more.

Thanks
G