Repository navigation
Does the EDG compiler completely support C++20 modules? #303
|
ITNOA Hi, Does the EDG compiler completely support C++20 modules? (100% conformance C++ ISO standard) |
Replies: 4 comments 1 reply
|
I generate report with AI with below plan: Plan: Verify C++20 modules in g++ emulation mode (EDG vs GCC 15.1)Phase 0 — Preconditions
Phase 1 — Build
Phase 2 — Differential smoke testsScratch area .tmp/agent-gnu-modules/ (visible to docker), run with edgy --runs-dir per skill edg-agent-temp-files. For every case: compile once with EDG (--c++20 --gnu_version=150100 --modules) and once with real g++ -std=c++20 -fmodules-c++20 from the dev-env base, then compare accept/reject and diagnostic classes (not exact wording).
Phase 3 — Suite baseline in gnu mode
Phase 4 — Report
|
|
opencode with generated: EDG C++20 Modules in gnu Emulation Mode — Verification ReportDate: 2026-10-15 / 2026-10-16 1. Executive summary
The one-line fix opportunity: handle the remaining float kinds in 2. The blocker bug2.1 Reproduction# In the docker dev-env (GCC 15.3.1 base), with build/gcc built:
. build/gcc/environment.sh
cd <scratch>
cat > f1.ixx <<'EOF'
export module m;
export int add(int a, int b) { return a + b; }
EOF
# Works (plain C++20):
eccp --c++20 --modules --module_interface f1.ixx # rc=0, IFC written
# Fails (gnu emulation — ANY --gnu_version value):
eccp --c++20 --gnu_version=150300 --modules --module_interface f1.ixx
# Catastrophic error: an IFC file could not be produced for the current
# translation unit
# one or more entities cannot currently be written to an IFC file
# rc=4Content-independent: 2.2 Backtrace (gdb, debug build)Break on Inspected in gdb at the breakpoint:
2.3 Causal chain
Plain 3. Differential test results (EDG gnu mode vs real g++ 15.3.1)3.1 MethodEach scenario ran self-contained per toolchain (EDG compiles interface + 3.2 Scenarios and verdicts
Every EDG divergence is the same 3.3 Test sources (as used)// s1 m.ixx
export module m;
export int add(int a, int b) { return a + b; }
export namespace math {
int twice(int v) { return 2 * v; }
}
// s1 main.cpp
extern "C" int printf(const char*, ...);
import m;
int main() { printf("%d %d\n", add(2, 3), math::twice(21)); return 0; }
// s3 p.ixx / m.ixx / main.cpp
export module m:p;
export int part() { return 7; }
export module m;
export import :p;
export int whole() { return part() + 1; }
extern "C" int printf(const char*, ...);
import m;
int main() { printf("%d\n", whole() + part()); return 0; }
// s4 m-impl.cpp / m.ixx / main.cpp
module m:impl;
int hidden() { return 40; }
export module m;
import :impl;
export int get() { return hidden() + 2; }
extern "C" int printf(const char*, ...);
import m;
int main() { printf("%d\n", get()); return 0; }
// s5 hh.h / main.cpp
#ifndef HH_H
#define HH_H
inline int hdr_val() { return 11; }
constexpr int hdr_c = 12;
#endif
extern "C" int printf(const char*, ...);
import "hh.h";
int main() { printf("%d %d\n", hdr_val(), hdr_c); return 0; }
// s6 m.ixx (GMF; also verifies __GNUC__ is defined in both engines)
module;
#define GMF_CONST 5
#ifdef __GNUC__
#define GMF_GNU 1
#else
#define GMF_GNU 0
#endif
export module m;
export int gmf() { return GMF_CONST; }
export int gnu_host() { return GMF_GNU; }
// s7 m.ixx (GNU extensions)
export module g;
export int gnu_fn(int x) {
__attribute__((unused)) int local = x;
typeof(x) y = x + 1;
int z = ({ int t = y * 2; t; });
return z;
}3.4 Command shapes# EDG side (per scenario; interface units first):
eccp --c++20 --gnu_version=150300 --modules --module_interface m.ixx
eccp --c++20 --gnu_version=150300 --modules main.cpp m.o -o prog
# Negative check (module keywords must be off by default in gnu mode):
eccp --c++20 --gnu_version=150300 main.cpp # rejects, like g++
# g++ side:
g++ -std=c++20 -fmodules-ts -x c++ -c m.ixx -o m.o
g++ -std=c++20 -fmodules-ts main.cpp m.o -o prog
g++ -std=c++20 main.cpp # rejects, matching EDGThis mirrors 3.5 Dialect notes worth keeping
4. Why this matters for vscode-cpptools#6302 (BMI format reality)
5. Baseline suite results (Phase 3)Command:
6. Recommended fixes and follow-ups
7. Environment and tooling work (Windows host, unplanned but required)The repo's supported workflow is docker-based ( 7.1 Setup that worked
7.2 One repo edit made (uncommitted, in working tree)
for mapped_dir in mapped_dirs:
try:
common_dir = Path(os.path.commonpath([mapped_dir, workspace_dir]))
except ValueError:
# On Windows, paths on different drives have no common prefix (e.g.,
# APPDATA on "C:" and the workspace on "E:"), so they cannot overlap.
continueWithout it, 7.3 CRLF→LF worktree normalizationWith the Git-for-Windows default Resolution applied to this clone:
7.4 Build
7.5 Scratch stateAll scratch material lived under 8. Bottom line
|
Definitely not. There are plenty of entity types that we cannot currently write out to IFC files. |
|
Some improvement with PR #315 |
Definitely not. There are plenty of entity types that we cannot currently write out to IFC files.