This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[C++ Patch] PR 51312


Hi,

this is a rejects valid issue with constexpr conversion operators and enums, eg:

struct X0
{
  constexpr operator int() const { return 1; }
};

enum E0 { e0 = X0() };

Given build_expr_type_conversion, we can handle the bug rather easily by using it when the enum doesn't have an underlying type, and directly perform_implicit_conversion_flags otherwise (as also suggested by Marc in the audit trail time ago). Some details: 1- Evidently, we can't just do everything with build_expr_type_conversion, similarly, eg, to finish_switch_cond, because we would not do the right thing for tests like F5 below, it would result in an ambiguous conversion. 2- I moved up, inside the value == NULL_TREE conditional, the existing code dealing with fixed underlying type enums, because now it's actually used only when we automatically compute the current value starting from the previous one (thus the tweaks to the existing testcases) 3- I'm taking the occasion to replace a pair of errors in build_expr_type_conversion with error + inform.

Thanks,
Paolo.

////////////////////////

Attachment: CL_51312
Description: Text document

Attachment: patch_51312
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]