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:

fmt/include/fmt/core.h

Line 122 in 1488df3

# if (FMT_HAS_CPP_ATTRIBUTE(deprecated) && __cplusplus >= 201402L) || \

or here:

fmt/include/fmt/core.h

Line 126 in 1488df3

# if defined(__GNUC__) || defined(__clang__)

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, ***@***.***> 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, ***@***.***> 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 > <#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:

• Small issues in docs #1 If __INTEL_COMPILER is defined, set FMT_DEPRECATED to /* Deprecated */
• Compiling errors VC2010 , QT4.8 #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 744302a 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, ***@***.***> wrote: Option 2 is not very complicated, so I'd go with that. Does 744302a <744302a> fix the problem? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#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, ***@***.***> 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 <#1273?email_source=notifications&email_token=AAJ3FJC56JVX6Y6TL7OOW7TQG27THA5CNFSM4IPTQQWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MBN5Y#issuecomment-525866743>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ3FJCXFFE3C2QNS3M3LITQG27THANCNFSM4IPTQQWA> .