RFE: configure probe for [[nodiscard]]

[Amir Kamil]

We currently require users to manually define UPCXX_USE_NODISCARD to 0 if the compiler does not support the [[nodiscard]] attribute but incorrectly reports __has_cpp_attribute(nodiscard). This should be straightforward to detect in a configure probe.

[Amir Kamil]

Copied from PR 368:

I don’t think a configure probe completely solves the problem. It would address the problem if the UPC++ is built with those flags using Clang, but it wouldn’t solve it if the library is built without those flags but the user passes them to the upcxx wrapper. So I don’t think we can remove UPCXX_USE_NODISCARD entirely.

‌

[Paul Hargrove]

More (newer) from PR 368:

Looking over where/how it is used in pushbuild (nightly CI), I find a correlation with -pedantic but not with the others. Some experimentation shows that use of [[nodiscard]] in the presence of -pedantic (and lacking-std=c++17) yields warnings about this attribute being specific to C++17 (or C++1y on older compilers). In other words, the __has_cpp_attribute query has truthfully answered only the “has” aspect but without any guarantee that its use won’t generate a warning.

[...]

However, related to possibly improved logic in response to issue 491, I’ve confirmed that use of [[clang::warn_unused_result]] as an alternative spelling does NOT get a pedantic warning. So, eventually preferring that when available might be sufficient to eliminate the only currently known (to me) use of UPCXX_USE_NODISCARD.

In other words: a configure probe might be used to select among [[clang::warn_unused_result]], [[gcc::warn_unused_result]] and [[nodiscard]].

[Amir Kamil]

One issue in trying to decide between multiple alternatives is that they may be silently accepted but ignored. In C++17:

All attributes unknown to an implementation are ignored without causing an error. (since C++17)

So we may need to branch on compiler at compile time rather than try to resolve this at configure time.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Clear past Milestone for open issues