export operator new and operator delete

[huangqinjin]

operator new and operator delete are exported in vcruntime_new.h

extern "C++" {
_VCRT_EXPORT_STD _NODISCARD _Ret_notnull_ _Post_writable_byte_size_(_Size) _VCRT_ALLOCATOR
void* __CRTDECL operator new(
    size_t _Size
    );

_VCRT_EXPORT_STD void __CRTDECL operator delete(
    void* _Block
    ) noexcept;
}

But according to https://eel.is/c++draft/basic.stc.dynamic#general-2, there functions are implicitly declared in global scope in each translation unit and are attached to the global module. So re-exporting them may violates https://eel.is/c++draft/module.interface#6

A redeclaration of an entity X is implicitly exported if X was introduced by an exported declaration; otherwise it shall not be exported.

Related llvm/llvm-project#90620.

[frederick-vs-ja]

Seems to be a compiler bug - sounds like that P2465R3 "Standard Library Modules std And std.compat" needs compilers to change.

Oh, perhaps I was wrong. They should be properly made available in the std module.

[StephanTLavavej]

extern "C++" will also attach to the global module.

@cdacamar, is this a Stuff Just Works scenario? I can't control your implicit declarations emitted by the compiler.

[cdacamar]

This does fall under the "it just works" scenario for MSVC. One possible workaround would be to move the vcruntime header to the GMF and do something like:

export using ::operator new;
export using ::operator delete;

To enable users to access them from the module interface.

[StephanTLavavej]

This also affects rttidata.h's forward declaration of type_info. Because I'm lazy, I'd like the compiler to take care of its own implicit declarations (i.e. creating special exemptions from the "must export on first decl" rule), instead of having to restructure how I export VCRuntime entities yet again.

[huangqinjin]

Could we adopt export using for operator new, operator delete as well as type_info?

By removing _VCRT_EXPORT_STD from their declarations and export using them in std.ixx, clang can import std from STL for example:

main.cpp

import std;
int main() {
    std::println("{}", "Hello, World!");
}

by command

clang -std=c++23 -Wno-reserved-module-identifier -Wno-include-angled-in-module-purview -fprebuilt-module-path=. -fmodule-output=std.pcm -x c++-module "%VCToolsInstallDir%/modules/std.ixx" -x c++ main.cpp -o hello.exe

For clang-cl, -x c++-module is not supported currently (I have sent a PR to LLVM to enable this), a workaround could be

std.cppm

#include <modules/std.ixx>

and build with command

clang-cl /EHsc /std:c++latest -Wno-reserved-module-identifier -Wno-include-angled-in-module-purview /clang:-fprebuilt-module-path=. /clang:-fmodule-output -I"%VCToolsInstallDir%/" std.cppm main.cpp /Fehello.exe

[StephanTLavavej]

At this point I haven't yet validated Clang with import std;. My preference would be for them to similarly special-case their pre-declarations, but if I must modify std.ixx then I will.

[frederick-vs-ja]

Could we adopt export using for operator new, operator delete as well as type_info?

IMO type_info shouldn't be treated specially as it is not implicitly declared.

[huangqinjin]

Could we adopt export using for operator new, operator delete as well as type_info?

IMO type_info shouldn't be treated specially as it is not implicitly declared.

It is at least for MSVC and clang-cl, if you declare union type_info; without any file included, compilers still complain about different declarations.

[huangqinjin]

Since operator new and operator delete are implicitly declared, do they really need to be exported? Anyway we need to export the definition of type_info.