Intel compiler discussion issue

Intel support is just about the only thing holding up version 2.6.2; there are now three open PRs on it. I've been working with Intel's support team, and they would like standalone examples of the bugs if possible. This helps track the progress, and is a call for standalone examples of the bugs.

PR 1: #2573: Initial support for “OneAPI” Intel compilers, using CI for the first time. (We’ve always supported older compilers, like 18 & 19, but had no CI and only tested C++11 - C++14 was actually C++11 due to a typo)

• arg()/arg{} transformation lifetime issue
  • Submitted as intel bug 04916223 on https://supporttickets.intel.com
    • Closed to due to no priority license
    • Needs standalone example if possible
• Using Constructor() = default is broken, we have to use Constructor {} instead in several places. Also ~Destructor() = default, too.

PR 2: #2729: Builds / reimplements PR 1, from someone else, but also address new C++17 issues since we have never tested with C++17 on earlier compilers (14 either, actually, due to a typo):

• Intel complier can’t compile enable_if_t<!all_of<is_positional<Args>...>::value> - have to use workaround to define in multiple parts
  • Three times, one time was not too bad, but one of them really should have been possible to write inline. It really doesn’t like complex template arguments.
  • Submitted as intel bug 04916230 on https://supporttickets.intel.com
    • Closed to due to no priority license
    • Needs standalone example if possible
• Weird warning had to be added: If you are encountering an 'error: name followed by "::" must be a class or namespace name’ with the Intel compiler and a noexcept function here, try to use noexcept(true) instead of plain noexcept.
  • Includes a test change to compile
• #if defined(__cpp_fold_expressions) && !defined(__INTEL_COMPILER) Intel compiler produces an internal error on this fold expression (This was broken on ICC 19 too)
  • Currently being worked on by the compiler team
• We have to add <aligned_new> to get ICC to follow the standard, but that seems to be a known compatibly issue

PR 3: #2769 Just opened yesterday to try icpx. The CI configs may have an issue there, it’s not running at all yet.

@ax3l @mkuron @tobiasleibner @YannickJadoul @bstaletic might be interested.

I'm thinking about adding a workaround def so that we can disable the workarounds at will, to see if they are still needed. That might be the best way forward for us without interfering with getting the problems fixed upstream.

Review PRs #2573, #2729, and #2769, along with the Intel compiler bugs and the CI configurations described in this issue. Begin by determining whether standalone examples can reproduce the reported failures and whether the icpx CI configuration runs; done requires a decided path for the workarounds and reproducible Intel support.