Styjun

Can someone explain the English 'W' sound?

What kind of world would drive brains to evolve high-throughput sensory?

Why are Oscar, India, and X-Ray (O, I, and X) not used as taxiway identifiers?

Why did modems have speakers?

Is there a way to shorten this while condition?

Found more old paper shares from broken up companies

Why did NASA use Imperial units?

Ultraproduct of Dividing Lines

Pgfplots fillbetween and Tikz shade

What is "It is x o'clock" in Japanese with subject

Are there any English words pronounced with sounds/syllables that aren't part of the spelling?

Adding gears to my grandson's 12" bike

Can we have too many dialogue tags and follow up actions?

If I have the Armor of Shadows Eldritch Invocation do I know the Mage Armor spell?

Killing a star safely

Can you find Airpod Case using Find my iPhone?

Can GPL and BSD licensed applications be used for government work?

Why can't a country print its own money to spend it only abroad?

Why does the salt in the oceans not sink to the bottom?

German phrase for 'suited and booted'

Can't understand how static works exactly

how to add 1 milliseconds on a datetime string?

Impact of throwing away fruit waste on a peak > 3200 m above a glacier

On the history of Haar measure

clang complains about constexpr function in case for switch statement

Why can't variables be declared in a switch statement?inline constexpr function definition legal or not? gcc (ok) vs clang (error)Replacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsGCC accepts `constexpr struct s;` but Clang rejects it. Who is correct?Why does the C++ compiler makes it possible to declare a function as constexpr, which can not be constexpr?Is function pointer comparison in a constexpr function allowed?Clang 3.7.0 complains of class not being literal because it is not an aggregate and has no constexpr constructorsLinker error for constexpr static member variable in gcc and clangNon-const constexpr member function does not compile with Intel compilerConstexpr static member function usage

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;

11

1

struct X
 
 enum class E
 
 A,B
 ;

 static constexpr X A()
 
 return XE::A;
 

 static constexpr X B()
 
 return XE::B;
 

 constexpr operator E() const
 
 return a;
 
 E a;
;

template <typename T>
struct Y

 void f()
 
 // without this line clang errs
 // const auto & x = this->x;
 switch(x)
 
 case X::A():
 case X::B():
 default: return;
 
 

 X x = X::A();
;

int main()

 Y<int>.f();

Without the marked line in the snippet clang gives the following error:

error: case value is not a constant expression case

X::B():

However I tried gcc and it compiled fine. Anybody knows if gcc is being lenient or clang has some bug?

See on godbolt (clang 8.0.0): https://godbolt.org/z/ETe5WQ
However (gcc 8.3) compiles fine (also on godbolt) and tried other versions of gcc and were also fine

Update:

opened a bug

c++ c++11

share|improve this question

edited Mar 26 at 15:43

mkmostafa

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @mkmostafa if you suspect compiler error it would not hurt to specify compiler versions you were using both gcc and clang.
  
  – Slava
  Mar 26 at 14:41
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  It compiles if you change switch(x) to switch(this->x)
  
  – Tharwen
  Mar 26 at 14:44
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Also compiles with clang 5 and clang 6: godbolt.org/z/KHMnoX I suggest filing a bug at bugs.llvm.org
  
  – chtz
  Mar 26 at 14:55
  

  
  
  
  

add a comment | 

11

1

struct X
 
 enum class E
 
 A,B
 ;

 static constexpr X A()
 
 return XE::A;
 

 static constexpr X B()
 
 return XE::B;
 

 constexpr operator E() const
 
 return a;
 
 E a;
;

template <typename T>
struct Y

 void f()
 
 // without this line clang errs
 // const auto & x = this->x;
 switch(x)
 
 case X::A():
 case X::B():
 default: return;
 
 

 X x = X::A();
;

int main()

 Y<int>.f();

Without the marked line in the snippet clang gives the following error:

error: case value is not a constant expression case

X::B():

However I tried gcc and it compiled fine. Anybody knows if gcc is being lenient or clang has some bug?

See on godbolt (clang 8.0.0): https://godbolt.org/z/ETe5WQ
However (gcc 8.3) compiles fine (also on godbolt) and tried other versions of gcc and were also fine

Update:

opened a bug

c++ c++11

share|improve this question

edited Mar 26 at 15:43

mkmostafa

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @mkmostafa if you suspect compiler error it would not hurt to specify compiler versions you were using both gcc and clang.
  
  – Slava
  Mar 26 at 14:41
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  It compiles if you change switch(x) to switch(this->x)
  
  – Tharwen
  Mar 26 at 14:44
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Also compiles with clang 5 and clang 6: godbolt.org/z/KHMnoX I suggest filing a bug at bugs.llvm.org
  
  – chtz
  Mar 26 at 14:55
  

  
  
  
  

add a comment | 

struct X
 
 enum class E
 
 A,B
 ;

 static constexpr X A()
 
 return XE::A;
 

 static constexpr X B()
 
 return XE::B;
 

 constexpr operator E() const
 
 return a;
 
 E a;
;

template <typename T>
struct Y

 void f()
 
 // without this line clang errs
 // const auto & x = this->x;
 switch(x)
 
 case X::A():
 case X::B():
 default: return;
 
 

 X x = X::A();
;

int main()

 Y<int>.f();

Without the marked line in the snippet clang gives the following error:

error: case value is not a constant expression case

X::B():

However I tried gcc and it compiled fine. Anybody knows if gcc is being lenient or clang has some bug?

See on godbolt (clang 8.0.0): https://godbolt.org/z/ETe5WQ
However (gcc 8.3) compiles fine (also on godbolt) and tried other versions of gcc and were also fine

Update:

opened a bug

c++ c++11

share|improve this question

edited Mar 26 at 15:43

mkmostafa

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

struct X
 
 enum class E
 
 A,B
 ;

 static constexpr X A()
 
 return XE::A;
 

 static constexpr X B()
 
 return XE::B;
 

 constexpr operator E() const
 
 return a;
 
 E a;
;

template <typename T>
struct Y

 void f()
 
 // without this line clang errs
 // const auto & x = this->x;
 switch(x)
 
 case X::A():
 case X::B():
 default: return;
 
 

 X x = X::A();
;

int main()

 Y<int>.f();

share|improve this question

edited Mar 26 at 15:43

mkmostafa

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

share|improve this question

edited Mar 26 at 15:43

mkmostafa

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

asked Mar 26 at 14:29

mkmostafamkmostafa

1,41611 gold badge1010 silver badges3030 bronze badges

2 Answers
2

active

oldest

votes

12

Clang (8.0.0) has a bug here.

If you write constexpr auto A = X::A(); and use case A: in your switch statement, you get the same compile error (saying that A is not a constant expression).

If you remove the cases, however, it compiles fine (which implies that A is a valid constexpr => a contradiction to the previous error).

Moreover, switch(x) fails while switch(this->x) succeeds. Since x == this->x in your case, this is definitely a bug.

As chtz mentioned, clang (5/6) seem to work just fine. That's not an argument, but an apparent regression.

Update: As mentioned by the OP, they filed a bug report.

share|improve this answer

edited Mar 27 at 9:57

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

add a comment | 

2

It appears clang doesn't work out that switch(x) is a switch on the enum X::E.

If you add an explicit cast to X::E (static_cast or C-style or whatever) your code compiles without your change.

This only happens when your class is a template.

Using switch(this->x) also works.

As whenever x is a member of the class, x is just another name for this->x even in a template, this has to be a clang bug.

The rules for how you can do a switch on a non-enum/integral type are interesting, in that they rely on the existence of an unspecified casting operator to any enum or integral type in the switch expression, and then invoke the same cast in the case expression.

share|improve this answer

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55359614%2fclang-complains-about-constexpr-function-in-case-for-switch-statement%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

12

Clang (8.0.0) has a bug here.

If you write constexpr auto A = X::A(); and use case A: in your switch statement, you get the same compile error (saying that A is not a constant expression).

If you remove the cases, however, it compiles fine (which implies that A is a valid constexpr => a contradiction to the previous error).

Moreover, switch(x) fails while switch(this->x) succeeds. Since x == this->x in your case, this is definitely a bug.

As chtz mentioned, clang (5/6) seem to work just fine. That's not an argument, but an apparent regression.

Update: As mentioned by the OP, they filed a bug report.

share|improve this answer

edited Mar 27 at 9:57

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

add a comment | 

12

Clang (8.0.0) has a bug here.

If you write constexpr auto A = X::A(); and use case A: in your switch statement, you get the same compile error (saying that A is not a constant expression).

If you remove the cases, however, it compiles fine (which implies that A is a valid constexpr => a contradiction to the previous error).

Moreover, switch(x) fails while switch(this->x) succeeds. Since x == this->x in your case, this is definitely a bug.

As chtz mentioned, clang (5/6) seem to work just fine. That's not an argument, but an apparent regression.

Update: As mentioned by the OP, they filed a bug report.

share|improve this answer

edited Mar 27 at 9:57

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

add a comment | 

Clang (8.0.0) has a bug here.

If you write constexpr auto A = X::A(); and use case A: in your switch statement, you get the same compile error (saying that A is not a constant expression).

If you remove the cases, however, it compiles fine (which implies that A is a valid constexpr => a contradiction to the previous error).

Moreover, switch(x) fails while switch(this->x) succeeds. Since x == this->x in your case, this is definitely a bug.

As chtz mentioned, clang (5/6) seem to work just fine. That's not an argument, but an apparent regression.

Update: As mentioned by the OP, they filed a bug report.

share|improve this answer

edited Mar 27 at 9:57

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

share|improve this answer

edited Mar 27 at 9:57

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

answered Mar 26 at 15:00

andreeeandreee

2,2971212 silver badges2828 bronze badges

2

It appears clang doesn't work out that switch(x) is a switch on the enum X::E.

If you add an explicit cast to X::E (static_cast or C-style or whatever) your code compiles without your change.

This only happens when your class is a template.

Using switch(this->x) also works.

As whenever x is a member of the class, x is just another name for this->x even in a template, this has to be a clang bug.

The rules for how you can do a switch on a non-enum/integral type are interesting, in that they rely on the existence of an unspecified casting operator to any enum or integral type in the switch expression, and then invoke the same cast in the case expression.

share|improve this answer

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

add a comment | 

2

It appears clang doesn't work out that switch(x) is a switch on the enum X::E.

If you add an explicit cast to X::E (static_cast or C-style or whatever) your code compiles without your change.

This only happens when your class is a template.

Using switch(this->x) also works.

As whenever x is a member of the class, x is just another name for this->x even in a template, this has to be a clang bug.

The rules for how you can do a switch on a non-enum/integral type are interesting, in that they rely on the existence of an unspecified casting operator to any enum or integral type in the switch expression, and then invoke the same cast in the case expression.

share|improve this answer

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

add a comment | 

It appears clang doesn't work out that switch(x) is a switch on the enum X::E.

If you add an explicit cast to X::E (static_cast or C-style or whatever) your code compiles without your change.

This only happens when your class is a template.

Using switch(this->x) also works.

As whenever x is a member of the class, x is just another name for this->x even in a template, this has to be a clang bug.

The rules for how you can do a switch on a non-enum/integral type are interesting, in that they rely on the existence of an unspecified casting operator to any enum or integral type in the switch expression, and then invoke the same cast in the case expression.

share|improve this answer

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

share|improve this answer

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges

answered Mar 26 at 17:33

Yakk - Adam NevraumontYakk - Adam Nevraumont

195k2121 gold badges214214 silver badges404404 bronze badges