consteval function not allowed in default argument to constexpr constructor #48230

andreasfertig · 2021-01-26T15:00:23Z


Bugzilla Link	48886
Version	11.0
OS	All
CC	@AaronBallman,@zygoloid

Extended Description

Hello,

the following valid code is currently rejected by Clang 11 and trunk (https://godbolt.org/z/645McM):

consteval int Fun() { return 0; }

struct Test {
  constexpr Test(int loc = Fun()) {}
};

Test t{};

The error is:

<source>:4:28: error: cannot take address of consteval function 'Fun' outside of an immediate invocation
  constexpr Test(int loc = Fun()) {}
                           ^
<source>:1:15: note: declared here
consteval int Fun() { return 0; }
              ^
1 error generated.
Compiler returned: 1

I had a brief communication with Richard Smith who confirmed that the code above is valid.

I assume this bug is similar to #47058

Best,

Andreas

The text was updated successfully, but these errors were encountered:

AaronBallman · 2021-10-14T19:27:21Z

*** Bug llvm/llvm-bugzilla-archive#51483 has been marked as a duplicate of this bug. ***

AaronBallman · 2021-10-21T13:09:44Z

*** Bug #47058 has been marked as a duplicate of this bug. ***

AaronBallman · 2021-11-27T04:40:34Z

mentioned in issue llvm/llvm-bugzilla-archive#51483

Izaron · 2022-02-12T19:54:36Z

Thanks for the issue! I suggested a possible fix, which affects the ParmVarDecl's custom AST visitor - https://reviews.llvm.org/D119646

llvmbot · 2022-02-12T22:57:10Z

@llvm/issue-subscribers-clang-frontend

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. Signed-off-by: Kefu Chai <tchaikov@gmail.com>

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. in this change, a new library is added for introducing the macro of "SEASTAR_BROKEN_SOURCE_LOCATION", if it is defined we'd have to use the homebrew implementation of source_location even the header file of <source_location> or <experimental/source_location> can be found by the C++ compiler. Signed-off-by: Kefu Chai <tchaikov@gmail.com>

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. in this change, a new library is added for introducing the macro of "SEASTAR_BROKEN_SOURCE_LOCATION", if it is defined we'd have to use the homebrew implementation of source_location even the header file of <source_location> or <experimental/source_location> can be found by the C++ compiler. please note, -std=c++20 is not added to CMAKE_REQUIRED_FLAGS when performing the test, because we want to ensure that we are using the same CXX_FLAGS as the ones when compiling std-compat.hh. Signed-off-by: Kefu Chai <tchaikov@gmail.com>

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. in this change, a new library is added for introducing the macro of "SEASTAR_BROKEN_SOURCE_LOCATION", if it is defined we'd have to use the homebrew implementation of source_location even the header file of <source_location> or <experimental/source_location> can be found by the C++ compiler. please note, -std=c++20 is not added to CMAKE_REQUIRED_FLAGS when performing the test, because we want to ensure that we are using the same CXX_FLAGS as the ones when compiling std-compat.hh. Signed-off-by: Kefu Chai <tchaikov@gmail.com> Message-Id: <20220516151733.411546-1-tchaikov@gmail.com>

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. in this change, a new library is added for introducing the macro of "SEASTAR_BROKEN_SOURCE_LOCATION", if it is defined we'd have to use the homebrew implementation of source_location even the header file of <source_location> or <experimental/source_location> can be found by the C++ compiler. please note, -std=c++20 is not added to CMAKE_REQUIRED_FLAGS when performing the test, because we want to ensure that we are using the same CXX_FLAGS as the ones when compiling std-compat.hh. Signed-off-by: Kefu Chai <tchaikov@gmail.com>

in a recent clang change, __builtin_source_location was added. see https://reviews.llvm.org/rGd61487490022 . but a bug in clang frontend pratically prevents us from using it. see llvm/llvm-project#48230. so before this issue is fixed, we have to prevent clang from using the builtin source location implementation. in this change, a new library is added for introducing the macro of "SEASTAR_BROKEN_SOURCE_LOCATION", if it is defined we'd have to use the homebrew implementation of source_location even the header file of <source_location> or <experimental/source_location> can be found by the C++ compiler. please note, -std=c++20 is not added to CMAKE_REQUIRED_FLAGS when performing the test, because we want to ensure that we are using the same CXX_FLAGS as the ones when compiling std-compat.hh. Signed-off-by: Kefu Chai <tchaikov@gmail.com> Message-Id: <20220519134839.1818862-2-tchaikov@gmail.com>

jyknight · 2022-05-30T14:56:02Z

Note that this bug is causing std::source_location in libstdc++ to be broken -- and also effectively blocking source_location for libc++, https://reviews.llvm.org/D120634 (not much point in committing it if nobody can use it).

tstellar · 2022-06-01T04:05:59Z

@jwakely

llvm/llvm-project#48230

llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 11, 2021

llvmbot added the confirmed Verified by a second party label Jan 26, 2022

EugeneZelenko added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Feb 12, 2022

tbaederr mentioned this issue Apr 5, 2022

consteval calls in default args #54744

Closed

jyknight mentioned this issue May 30, 2022

Clang failed to use std::source_location::current() in default argument #55769

Closed

jyknight added the libstdc++ GNU libstdc++ C++ standard library label May 30, 2022

ChuanqiXu9 assigned ChuanqiXu9 and unassigned ChuanqiXu9 May 31, 2022

jyknight mentioned this issue Jun 1, 2022

Clang reporting multiple consteval usage violations, violations do not appear to be violations? #55601

Closed

ChuanqiXu9 closed this as completed in a4f8590 Jun 7, 2022

Qup42 mentioned this issue Sep 3, 2022

Refactor the unit tests for the SPARQL ANTLR parser ad-freiburg/qlever#767

Merged

hasselmm added a commit to hasselmm/PropertyExperiment that referenced this issue Dec 20, 2023

Workaround broken std::source_location in Clang 15

fcd3444

llvm/llvm-project#48230

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

consteval function not allowed in default argument to constexpr constructor #48230

consteval function not allowed in default argument to constexpr constructor #48230

andreasfertig commented Jan 26, 2021 •

edited by jyknight

AaronBallman commented Oct 14, 2021

AaronBallman commented Oct 21, 2021

AaronBallman commented Nov 27, 2021

Izaron commented Feb 12, 2022

llvmbot commented Feb 12, 2022

jyknight commented May 30, 2022

tstellar commented Jun 1, 2022

consteval function not allowed in default argument to constexpr constructor #48230

consteval function not allowed in default argument to constexpr constructor #48230

Comments

andreasfertig commented Jan 26, 2021 • edited by jyknight

Extended Description

AaronBallman commented Oct 14, 2021

AaronBallman commented Oct 21, 2021

AaronBallman commented Nov 27, 2021

Izaron commented Feb 12, 2022

llvmbot commented Feb 12, 2022

jyknight commented May 30, 2022

tstellar commented Jun 1, 2022

andreasfertig commented Jan 26, 2021 •

edited by jyknight