fix Issue 15374 - Move genCmain into Compiler struct.

[ibuclaw]

Probably a good time to think about what to do with entrypoint and rootHasMain. Keep as top-level vars? Or move into Global.

[dlang-bot]

Thanks for your pull request, @ibuclaw!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	15374	blocker	[internal] Nothing should import ddmd.mars

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#7534"

[wilzbach]

Regarding:

CC="c++" /home/braddr/sandbox/at-client/release-build/install/freebsd/bin32/dmd -lib -of../generated/freebsd/release/32/lexer.a -m32 -J../generated/freebsd/release/32 -L-lstdc++ -version=MARS  -w -de -O -release -inline dmd/console.d dmd/entity.d dmd/errors.d dmd/globals.d dmd/id.d dmd/identifier.d dmd/lexer.d dmd/tokens.d dmd/utf.d dmd/root/array.d dmd/root/ctfloat.d dmd/root/file.d dmd/root/filename.d dmd/root/outbuffer.d dmd/root/port.d dmd/root/rmem.d dmd/root/rootobject.d dmd/root/stringtable.d dmd/root/hash.d
dmd/doc.d(356): Error: file "default_ddoc_theme.ddoc" cannot be found or not in a path specified with -J
posix.mak:445: recipe for target '../generated/freebsd/release/32/lexer.a' failed

The other targets do seem to have -J$G -J../res (instead of just -J$G), but the error suggests that now doc.d is imported.

[ibuclaw]

I'm not sure what that has to do with this PR.

It built locally just fine for me.

[wilzbach]

It built locally just fine for me.

Maybe you didn't clean your build directory. I can reproduce the failure locally and as said this will fix it:

diff --git a/src/posix.mak b/src/posix.mak
index a025bb42f..9a42370ab 100644
--- a/src/posix.mak
+++ b/src/posix.mak
@@ -442,7 +442,7 @@ $G/backend.a: $(G_OBJS) $(SRC_MAKE)
 	$(AR) rcs $@ $(G_OBJS)
 
 $G/lexer.a: $(LEXER_SRCS) $(LEXER_ROOT) $(HOST_DMD_PATH) $(SRC_MAKE)
-	CC="$(HOST_CXX)" $(HOST_DMD_RUN) -lib -of$@ $(MODEL_FLAG) -J$G -L-lstdc++ $(DFLAGS) $(LEXER_SRCS) $(LEXER_ROOT)
+	CC="$(HOST_CXX)" $(HOST_DMD_RUN) -lib -of$@ $(MODEL_FLAG) -J$G -J../res -L-lstdc++ $(DFLAGS) $(LEXER_SRCS) $(LEXER_ROOT)
 
 $G/dmd_frontend: $(FRONT_SRCS) $D/gluelayer.d $(ROOT_SRCS) $G/newdelete.o $G/lexer.a $(STRING_IMPORT_FILES) $(HOST_DMD_PATH)
 	CC="$(HOST_CXX)" $(HOST_DMD_RUN) -of$@ $(MODEL_FLAG) -vtls -J$G -J../res -L-lstdc++ $(DFLAGS) $(filter-out $(STRING_IMPORT_FILES) $(HOST_DMD_PATH),$^) -version=NoBackend

But I'm still not sure why your changes are leading to the lexer importing doc.d

[wilzbach]

Problem is due to globals.d now importing compiler.d:

> ag "import dmd.compiler"
dmd/mars.d
30:import dmd.compiler;

dmd/globals.d
22:import dmd.compiler;

dmd/dsymbolsem.d
30:import dmd.compiler;

[ibuclaw]

Rebased.

[PetarKirov]

LGTM, just fix the build errors.

[PetarKirov]

Import dmd.semantic2 and dmd.semantic3 instead.

[ibuclaw]

object.Error@src/rt/minfo.d(371): Cyclic dependency between module dmd.lexer and dmd.traits
dmd.lexer* ->
dmd.globals ->
dmd.compiler ->
dmd.dsymbolsem ->
dmd.expressionsem ->
dmd.traits* ->
dmd.dsymbol ->
dmd.lexer*

😨

[jacob-carlborg]

Perhaps the module constructor in lexer.d can be replaced with a CTFE function.

[wilzbach]

Perhaps the module constructor in lexer.d can be replaced with a CTFE function.

Yes, let's kill the module constructor with CTFE 🔥
-> #7623

[ibuclaw]

Regarding the requirement of -J../res, this should not flag up if all imports are nested in functions.

[wilzbach]

Regarding the requirement of -J../res, this should not flag up if all imports are nested in functions.

DMD only does lazy imports for templates. Anyhow we shouldn't need to add -J ../res because that means that parser.a library depends on doc.d, which it didn't before this PR.

[ibuclaw]

What about the (currently unused) dmd.frontend? initDMD() sure sounds like a tempting place to initialize dmd-specific global fields.

[jacob-carlborg]

initDMD is intended to be used when using the DMD library (Dub package).

[wilzbach]

initDMD is intended to be used when using the DMD library (Dub package).

Yep and we want to be able to use Phobos for that to provide nice high-level wrappers.

Anyhow we shouldn't need to add -J ../res because that means that parser.a library depends on doc.d, which it didn't before this PR.

OTOH considering how much pain lexer.a is bringing us - compared to the little gain (people will use the DUB package anyways, I doubt anyone will use lexer.a as generated by the Makefile) - you might also want to ignore my statement.

[jacob-carlborg]

OTOH considering how much pain lexer.a is bringing us - compared to the little gain (people will use the DUB package anyways, I doubt anyone will use lexer.a as generated by the Makefile

I thought that was removed.

[wilzbach]

I thought that was removed.

Still there:

https://github.com/dlang/dmd/blob/master/src/posix.mak#L432
https://github.com/dlang/dmd/blob/master/src/posix.mak#L452

CC @RazvanN7

[RazvanN7]

If globals.d imports compiler.d then compiler.d should contain only files present in the parser library, otherwise we will end up adding semantic dependencies for the parser library.

[ibuclaw]

Indeed, however there are a couple settings that should be set up outside of global module, notably the vendor and version string. Both of which are used by the parser.

Perhaps now there's a frontend module I can dissolve global._init() and move the remaining field initialization to more relevant places.

[ibuclaw]

Rebased.

[ibuclaw]

Rebased again, reapplying auto-merge.