fmt v6.0.0 has a compiler error under Intel Compiler v19.0

[sharpe5]

Firstly, thank you for your fantastic work on this library. It really is soooo much nicer than chevron hell, especially when doing something simple like changing number of significant figures for a double.

So everything is working under Visual Studio 2017 v15.9. However, when I switch to Intel Compiler v19.0, it generates compiler errors.

Compiler errors:

3>[snip]\include\fmt\core.h(477): error : attribute does not apply to any entity
3>  using parse_context FMT_DEPRECATED = basic_parse_context<char>;
3>                      ^
3>
3>[snip]\fmt\include\fmt\core.h(478): error : attribute does not apply to any entity
3>  using wparse_context FMT_DEPRECATED = basic_parse_context<wchar_t>;
3>                       ^
3>
3>[snip]\fmt\include\fmt\format.h(2599): error : attribute does not apply to any entity
3>  using writer FMT_DEPRECATED = internal::writer;
3>               ^
3>
3>[snip]\fmt\include\fmt\format.h(2600): error : attribute does not apply to any entity
3>  using wwriter FMT_DEPRECATED =
3>                ^
3>
3>compilation aborted for main.cpp (code 2)
3>Done building project "main.vcxproj" -- FAILED.
9>------ Build started: Project: Project, Configuration: Debug x64 ------
9>  Project -> load.exe
========== Build: 8 succeeded, 1 failed, 46 up-to-date, 0 skipped ==========

[sharpe5]

Found a workaround.

Everything is compiling nicely now.

The fix is to compile in header-only mode (i.e. do not include format.cc and posix.cc within Visual Studio), and also #define FMT_DEPRECATED:

#define FMT_HEADER_ONLY
#define FMT_DEPRECATED // Necessary in v6.0.0 of fmt library to avoid a Intel C++ v19.0 compiler error.
// Add path to include files, e.g. "fmt/include", to project properties under "VC++ Directories" and "Include Directories".
#include <fmt/core.h>
#include <fmt/format.h>

int main()
{
  std::cout << "Hello World!\n";
  fmt::print("Hello, {}!", "world");
}

[vitaut]

Intel compiler should be disabled here:

https://github.com/fmtlib/fmt/blob/1488df3395e7efbca64b4a6b19f6985113e67a3a/include/fmt/core.h#L122

or here:

https://github.com/fmtlib/fmt/blob/1488df3395e7efbca64b4a6b19f6985113e67a3a/include/fmt/core.h#L126

Could you by any chance submit a PR since you in the best position to test it?

[sharpe5]

Ah, I get it. All I have to do is define the appropriate keyword for the
Intel Compiler in the code blocks you mentioned.

I will submit a PR tonight or tomorrow.

On Tue, 27 Aug 2019, 14:47 DesignREM support, [e-mail] wrote:

To be honest, although I have 25 years experience with programming in
general, my strengths are in C# and C. I am super keen to upgrade to C++,
and I am currently devoting the time to do so.

So I can certainly submit a pull request, but I cannot guarantee that it
will be optimal. You can always reject it if it's not up to scratch.

One quick question - what does FMT_DEPRECATED mean? Would it be enough to
define it if the Intel Compiler is detected, e.g. if __INTEL_COMPILER is
defined?

On Tue, 27 Aug 2019, 04:21 Victor Zverovich, [e-mail]
wrote:

Intel compiler should be disabled here:

https://github.com/fmtlib/fmt/blob/1488df3395e7efbca64b4a6b19f6985113e67a3a/include/fmt/core.h#L122

or here:

https://github.com/fmtlib/fmt/blob/1488df3395e7efbca64b4a6b19f6985113e67a3a/include/fmt/core.h#L126

Could you by any chance submit a PR since you in the best position to
test it?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/fmtlib/fmt/issues/1273?email_source=notifications&email_token=AAJ3FJFYJWW67WY5RVM2WQLQGSMSTA5CNFSM4IPTQQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5GLCGQ#issuecomment-525119770,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ3FJFL2LBGMC7WFYXG7STQGSMSTANCNFSM4IPTQQWA
.

[sharpe5]

Closed the pull request.

The problem is that the Intel Compiler generally accepts the [[deprecated]] attribute, but it does not on the following lines of code:

using parse_context FMT_DEPRECATED = basic_parse_context<char>;

using wparse_context FMT_DEPRECATED = basic_parse_context<wchar_t>;

using writer FMT_DEPRECATED = internal::writer;

using wwriter FMT_DEPRECATED =internal::basic_writer<internal::buffer_range<wchar_t>>;

What make it weirder is that it will accept an _invalid_ token such as [[deprecatedZZZZ]] or [[gnu:deprecatedZZZZZ]] on those lines, but it will not accept a valid token such as [[deprecated]]. This looks and feels like a bug in the compiler to me.

The [[deprecated]] token works perfectly well on these lines of code:

struct FMT_DEPRECATED convert_to_int
    : bool_constant<!std::is_arithmetic<T>::value &&
                    std::is_convertible<T, int>::value> {};

FMT_DEPRECATED static constexpr unsigned long long TYPES = types;

FMT_DEPRECATED format_specs* spec() { return specs_; }

template <typename Range>
using basic_writer FMT_DEPRECATED = internal::basic_writer<Range>;

Given this odd behavior, here are two possible solutions:

• #1 If __INTEL_COMPILER is defined, set FMT_DEPRECATED to /* Deprecated */
• #2 Or, if __INTEL_COMPILER is defined, do not deprecate the four lines that it is failing on (as there appears to be no way to, in any case).

I think it's probably more important that it compiles without any issues, so my vote is with #1.

Option #2 is possible, but it would make the code more complicated?

[vitaut]

Option 2 is not very complicated and more localized, so I'd go with that. Does https://github.com/fmtlib/fmt/commit/744302add085f30120c57f73cddbcb826cc92de9 fix the problem?

[sharpe5]

That's a fantastic idea. I'll test it out in a few hours.

On Wed, 28 Aug 2019, 14:03 Victor Zverovich, [e-mail]
wrote:

Option 2 is not very complicated, so I'd go with that. Does 744302a
https://github.com/fmtlib/fmt/commit/744302add085f30120c57f73cddbcb826cc92de9
fix the problem?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/fmtlib/fmt/issues/1273?email_source=notifications&email_token=AAJ3FJC3CCQKKIZ6ID2PQHLQGZZODA5CNFSM4IPTQQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5LBHEQ#issuecomment-525734802,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ3FJHP33II6L2CLQGPF7TQGZZODANCNFSM4IPTQQWA
.

[sharpe5]

Works perfectly! Issue closed.

I've also made the authors of the Intel Compiler v19.0 aware of this problem, so hopefully it will disappear in the future, and we can only have this workaround enabled for pre-v19.01 versions of the compiler.

[vitaut]

Great, thanks for reporting the issue and verifying the workaround.

[sharpe5]

And thank you for writing {fmt}. I come from a C/C#/Python background, and
using chevrons is uncomfortably clunky and almost impossibly verbose in
many circumstances. You are making the world better, one deleted "<<" at a
time :)

On Wed, 28 Aug 2019, 19:28 Victor Zverovich, [e-mail]
wrote:

Great, thanks for reporting the issue and verifying the workaround.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fmtlib/fmt/issues/1273?email_source=notifications&email_token=AAJ3FJC56JVX6Y6TL7OOW7TQG27THA5CNFSM4IPTQQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MBN5Y#issuecomment-525866743,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ3FJCXFFE3C2QNS3M3LITQG27THANCNFSM4IPTQQWA
.