Repository navigation
[BUG] #792
Description
Describe the bug
cppfront produces CPP1 code that is no accepted by gcc-11.4 or clang-18.0.0
To Reproduce
- in issue_base.h
class IssueBase {
public:
virtual bool virtualConstFunction() const = 0;
virtual bool virtualFunction() = 0;
};
- in issue.cpp2
#include "issue_base.h"
Issue : type = {
virtualConstFunction : (this) -> bool = {
std::cout << "virtual const function called\n";
return true;
}
virtualFunction : (inout this) -> bool = {
std::cout << "virtual function called\n";
return false;
}
}
main : () = {
issue : Issue = ();
issue.virtualFunction();
issue.virtualConstFunction();
issue.virtualFunction();
}
Cppfront generates std::move(issue) for the last use of issue in main. This works fine if virtualConstFunction is the last function called but fails if virtualFunction is the last call.
gcc-11.4.0:
[proc] Executing command: /usr/bin/cmake --build /workspaces/cpp2_learn/build --config Debug --target issue -j 10 --
[build] [1/3 33% :: 0.007] Generating ../_cppfront/issue.cpp
[build] /workspaces/cpp2_learn/issue/issue.cpp2... ok (mixed Cpp1/Cpp2, Cpp2 code passes safety checks)
[build]
[build] [2/3 66% :: 1.423] Building CXX object issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o
[build] FAILED: issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o
[build] /usr/bin/g++ -I/workspaces/cpp2_learn/issue -isystem /workspaces/cpp2_learn/cppfront/cppfront/include -g -std=gnu++20 -MD -MT issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o -MF issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o.d -o issue/CMakeFiles/issue.dir/__/_cppfront/issue.cpp.o -c /workspaces/cpp2_learn/build/_cppfront/issue.cpp
[build] In file included from /workspaces/cpp2_learn/build/_cppfront/issue.cpp:7:
[build] /workspaces/cpp2_learn/issue/issue.cpp2: In instantiation of 'main()::<lambda(auto:80&&)> [with auto:80 = Issue]':
[build] /workspaces/cpp2_learn/issue/issue.cpp2:19:5: required from here
[build] /workspaces/cpp2_learn/issue/issue.cpp2:19:5: error: 'virtualFunction' was not declared in this scope
[build] 19 | issue.virtualFunction();
[build] | ^
[build] ninja: build stopped: subcommand failed.
clang-18.0.0:
[build] [1/3 33% :: 0.006] Generating ../_cppfront/issue.cpp
[build] /workspaces/cpp2_learn/issue/issue.cpp2... ok (mixed Cpp1/Cpp2, Cpp2 code passes safety checks)
[build]
[build] [2/3 66% :: 1.704] Building CXX object issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o
[build] FAILED: issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o
[build] /usr/bin/clang++-18 -I/workspaces/cpp2_learn/issue -isystem /workspaces/cpp2_learn/cppfront/cppfront/include -g -std=gnu++20 -MD -MT issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o -MF issue/CMakeFiles/issue.dir//_cppfront/issue.cpp.o.d -o issue/CMakeFiles/issue.dir/__/_cppfront/issue.cpp.o -c /workspaces/cpp2_learn/build/_cppfront/issue.cpp
[build] /workspaces/cpp2_learn/issue/issue.cpp2:19:17: error: use of undeclared identifier 'virtualFunction'
[build] 19 | CPP2_UFCS_0(virtualFunction, std::move(issue));
[build] | ^
[build] /workspaces/cpp2_learn/issue/issue.cpp2:19:5: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()' requested here
[build] 19 | CPP2_UFCS_0(virtualFunction, std::move(issue));
[build] | ^
[build] /workspaces/cpp2_learn/cppfront/cppfront/include/cpp2util.h:797:2: note: expanded from macro 'CPP2_UFCS_0'
[build] 797 | }(PARAM1)
[build] | ^
[build] 1 error generated.
[build] ninja: build stopped: subcommand failed.
The generated main:
#line 14 "/workspaces/cpp2_learn/issue/issue.cpp2"
auto main() -> int{
Issue issue {};
CPP2_UFCS_0(virtualFunction, issue);
CPP2_UFCS_0(virtualConstFunction, issue);
CPP2_UFCS_0(virtualFunction, std::move(issue));
}
If the std::move(...) is removed around issue both compilers accept the code.
Activity
JohelEGP commentedon Oct 30, 2023
For the implicit move, see #305 (comment).
You need to add
_ = issue;.To actually declare
Issueas anIssueBase,you need a
this: IssueBase;data member.To override the virtual functions,
you need
override thisandoverride inout thisparameters.iprtel commentedon Oct 30, 2023
Thanks. So my simplified test case is issue.cpp2. I still get the same error.
Thanks for the help on the inheritance. I struggled with that.
JohelEGP commentedon Oct 30, 2023
You need to discard the last use of
issue, without any calls.iprtel commentedon Oct 30, 2023
So if the last function you called is non-const you need to discard the object.
Thanks.
iprtel commentedon Oct 30, 2023
@JohelEGP sorry to come once again.
My understanding about the discarding after the last non-const call is not sufficient.
This
mainalso fixes the problem:Here the move is on
result:JohelEGP commentedon Oct 30, 2023
Rvalues are convertible to reference to
const,so printing
<<works because the rhs is taken by reference toconst.iprtel commentedon Oct 30, 2023
So why is the discard on
issueno longer needed? I thought that it was necessary since the last call hadinout thisand so the object counts as return value that needs to be discarded.JohelEGP commentedon Oct 30, 2023
operator<<typically looks likeoperator<<: (inout s: std::ostream, in x: T),so
xaccepts moved objects.iprtel commentedon Oct 30, 2023
Thanks for the explenation. But I'm more interessted why
is fine. While
requires a
_ = issue;JohelEGP commentedon Oct 30, 2023
That must be #749.
hsutter commentedon Nov 14, 2023
You're right, both should require
_ = issue;. Will fix.The issue is that I was trying out suppressing move-from-last-use if the last use was in an initializer, because of examples like
view: std::span = local_variable;when that was the last use oflocal_variable, which is an error for an rvalue. But that also suppresses a righteous move in examples likeresult := local_variable;. So I now agree those should be treated as rvalues too, and if that causes an error for an rvalue because there is no further us of that variable in scope, then the programmer must write an explicit discard of the variable.iprtel commentedon Nov 19, 2023
Are you at all concerned that people will just put explicit discards all over the place when trying to fix a compilation problem that the don't understand fully?
tomFlowee commentedon Dec 20, 2023
lets continue this topic on #901