Expose D frontend via DUB by wilzbach · Pull Request #7425 · dlang/dmd

wilzbach · 2017-12-12T03:17:00Z

Allows to use the entire frontend as a DUB package.

There's still an ugly lot of initialization needed and two hard-coded bits (platform, importPaths), but one can run through all semantic phases which is more than needed if we want to take the DMD as a library project serious ;-)

I will comment on the individual lines for which I would like to find a better solution.

Also note that I didn't add this to the test scripts yet as I am waiting for #7415 (allows to test the DUB package on Travis).

dlang-bot · 2017-12-12T03:17:01Z

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

wilzbach · 2017-12-12T03:18:50Z

wilzbach requested a review from WalterBright as a code owner just now

Btw @WalterBright this happens automatically because of

dmd/CODEOWNERS

Line 34 in f27ee71

src/ddmd/* @WalterBright

If you mind about this, we should improve the mappings.

wilzbach · 2017-12-12T03:19:35Z

dub.sdl


  sourceFiles \
    "src/ddmd/astbase.d" \
-    "src/ddmd/astbasevisitor.d" \


Same change required as inhttps://github.com//pull/7415 (atm moment the DUB file is outdated).

wilzbach · 2017-12-12T03:21:05Z

dub.sdl

+    "src/ddmd/libmach.d" platform="osx"
+
+  dependency "dmd:parser" version="*"
+  dependency "dmd:lexer" version="*"


FWIW splitting up dmd in four packages creates a noticeable overhead in terms of DUB compile times (compared to one big library file).

I thought it would be nice to be able to only pull in the lexer, i.e. for source code highlighting. But since Dub will currently download the whole DMD package anyway it doesn't matter that much.

Although, it would be nice to have some kind of enforcement of the separation between the different phases, to avoid that the lexer suddenly starts to depend on the rest of the front end.

Well I hope that in practice one doesn't need to constantly recompile libdmd.a, so it shouldn't matter too much.

wilzbach · 2017-12-12T03:21:45Z

src/ddmd/root/rmem.d

+    extern (C) void* allocmemory(size_t m_size) nothrow
+    {
+        return GC.malloc(m_size);
+    }


It seems like version(GC) isn't used actively (at least by anything that is part of the testsuite/CIs).

wilzbach · 2017-12-12T03:22:45Z

test/dub_package/source/app.d

+    Expression._init();
+    Objc._init();
+    builtin_init();
+}


Is there any chance we can move a generic initialization function into the DMD codebase?

Currently this is handled in mars.d, which contains the main function of DMD. This file should not be included in the Dub package, but I don't see why we can't move this to a separate function, called initFrontEnd which can be called both from the compiler and the Dub package. Perhaps we can add a new file with a shared constructor that is only part of the Dub package that calls this initFrontEnd function.

Perhaps we can add a new file with a shared constructor that is only part of the Dub package that calls this initFrontEnd function.

Yeah, I think this would be the best way to move forward. This file could also contain other convenience, modern D wrapper. How about ddmd/libdmd.d, ddmd/library.d, or ddmd/frontend.d?

I don't like ddmd/libdmd.d, the others are fine, I think I prefer ddmd/frontend.d. But I don't want to limit ourselves to this file. I think we should look at what we want to add and add it to the modules where it makes most sense. I don't mind adding several new modules and/or packages if that makes more sense. I don't have any problems with having only one symbol in a module if it doesn't fit anywhere else.

wilzbach · 2017-12-12T03:27:47Z

test/dub_package/source/app.d

+    import ddmd.id : Id;
+
+    init;
+    addImports(["/usr/include/dlang/dmd/"]);


This is the worst bit about this PR. While, for this test we could mock object.d, I think we should show potential users how they can add import paths as they most likely want to do so.
Ideas:

mock object.d

use sth. like ../../../druntime/import (i.e. depend on existing repo layout)

call DMD and search config strings

refactor config parsing from mars.d, s.t. it can be used here

wilzbach · 2017-12-12T03:34:46Z

test/dub_package/source/app.d

+    import ddmd.tokens : TOKeof;
+    import ddmd.id : Id;
+
+    init;


We still need to define all predefined versions, but addDefaultVersionIdentifiers is private.
Imho if I would be about to write an IDE plugin, I wouldn't want to keep this list in sync if DMD already has the logic.
For example, to import Phobos on Linux, I need this list:

import ddmd.cond : VersionCondition; VersionCondition.addPredefinedGlobalIdent("DigitalMars"); VersionCondition.addPredefinedGlobalIdent("Posix"); VersionCondition.addPredefinedGlobalIdent("linux"); VersionCondition.addPredefinedGlobalIdent("ELFv1"); VersionCondition.addPredefinedGlobalIdent("LittleEndian"); VersionCondition.addPredefinedGlobalIdent("CRuntime_Glibc"); VersionCondition.addPredefinedGlobalIdent("D_Version2"); VersionCondition.addPredefinedGlobalIdent("all"); VersionCondition.addPredefinedGlobalIdent("D_InlineAsm_X86_64"); VersionCondition.addPredefinedGlobalIdent("X86_64"); VersionCondition.addPredefinedGlobalIdent("D_HardFloat");

So any chance we can refactor addDefaultVersionIdentifiers and expose it?

wilzbach · 2017-12-12T03:43:41Z

test/dub_package/source/app.d

+        res.append(a);
+    }
+    global.path = res;
+}


Well, obviously it would be nice if the dmd "library` contains a couple of high-level wrapper, s.t. a potential author only has to interact with its shiny, modern D APIs.

wilzbach · 2017-12-14T01:19:17Z

OK, so I added a rudimentary dmd.conf detection which is a combination from findConfFile and a quick regex to parse the import paths.

-> this should now work on Travis

I don't like ddmd/libdmd.d, the others are fine, I think I prefer ddmd/frontend.d. But I don't want to limit ourselves to this file. I think we should look at what we want to add and add it to the modules where it makes most sense. I don't mind adding several new modules and/or packages if that makes more sense. I don't have any problems with having only one symbol in a module if it doesn't fit anywhere else.

-> I created ddmd/frontend.d and moved the initialization calls to this module to prime it.

Other points (now not displayed anymore):

We still need to define all predefined versions, but addDefaultVersionIdentifiers is private.
"obviously it would be nice if the dmd "library` contains a couple of high-level wrapper, s.t. a potential author only has to interact with its shiny, modern D APIs."

wilzbach · 2017-12-14T01:23:11Z

test/dub_package/.gitignore

@@ -1,6 +1,13 @@
+# Ignore all binary files (files without an extension)


As hopefully more examples will be added, ignoring all binary files in this directory avoids frequent updates of this file.

I think a cleaner solution would be put all dub artifacts in generated/ as well, using targetPath (see http://code.dlang.org/package-format?lang=sdl).

jacob-carlborg · 2017-12-14T08:25:41Z

dub.sdl

+    "src/ddmd/templateparamsem.d" \
+    "src/ddmd/semantic.d" \
+    "src/ddmd/sideeffect.d" \
+	"src/ddmd/statement.d" \


The indentation is wrong here.

jacob-carlborg · 2017-12-14T08:25:46Z

dub.sdl

+    "src/ddmd/typinf.d" \
+    "src/ddmd/utils.d" \
+	"src/ddmd/statement_rewrite_walker.d" \
+	"src/ddmd/statementsem.d" \


The indentation is wrong here.

jacob-carlborg · 2017-12-14T08:28:49Z

test/dub_package/README.md

+
+If you want to see the log output or want to pass additional options, use `--single`:
+
+  dub --single -v lexer.d


This line and line 10 doesn't have the same indentation. For code blocks I recommend the triple backticks.

jacob-carlborg · 2017-12-14T08:29:50Z

test/dub_package/README.md

@@ -0,0 +1,17 @@
+DMD as a library
+================


Personally I prefer the hash # for headers. Then I only need one character and don't have to add/remove characters if the title changes.

Yeah I usually use a mix of these styles in my markdown: === for the title and # for all headers within the file as the title usually changes seldom, but has more emphasis this way.
Anyhow I wouldn't mind at all to use a # if that's important, but I think there are more pressing issues than which flavor of Markdown should be used?

No, it's not that important. That's why I said it's my personal preference.

jacob-carlborg · 2017-12-14T08:30:57Z

test/dub_package/frontend.d

+    initDMD;
+    findImportPaths.addImports;
+
+    auto parse(Module m, string code) {


Opening curly braces on their own lines.

wilzbach · 2017-12-14T08:45:41Z

(addressed the comments & hopefully found the issue for the failing Travis test.)

jacob-carlborg · 2017-12-14T09:34:20Z

dub.sdl

+    "src/ddmd/safe.d" \
+    "src/ddmd/blockexit.d" \
+    "src/ddmd/printast.d" \
+    "src/ddmd/gluelayer.d"


Minor detail, it would be nice if the list was sorted alphabetically, unless it's sorted in some other way that I fail to see now.

jacob-carlborg · 2017-12-14T09:42:03Z

dub.sdl

+    "src/ddmd/libelf.d" platform="linux"
+
+   sourceFiles "src/ddmd/scanmach.d" \
+    "src/ddmd/libmach.d" platform="osx"


The last three files, I know they're not technically not part of the backend but I think they feel more geared towards the backend or code generation. Do we want to include them?

Currently they are required by some bits of the frontend (see below). Though I'm pretty sure, that these parts could versioned out in the future.

Remove libelf.d

/tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(lib.o):(.data.rel.ro+0x28): undefined reference to `_D4ddmd6libelf12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(lib_532_2d5.o): In function `_D4ddmd3lib7Library7factoryFZCQBcQBaQz': /home/seb/dlang/dmd/src/ddmd/lib.d:56: undefined reference to `LibElf_factory()' collect2: error: ld returned 1 exit status Error: linker exited with status 1

Remove gluelayer.d

/tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(dclass.o):(.data.rel.ro+0x20): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(denum.o):(.data.rel.ro+0x10): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(dmodule.o):(.data.rel.ro+0x28): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(dsymbol.o):(.data.rel.ro+0x30): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(dsymbolsem.o):(.data.rel.ro+0xd8): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(dsymbolsem_39a_657.o): In function `Semantic3Visitor::visit(FuncDeclaration*)': /home/seb/dlang/dmd/src/ddmd/dsymbolsem.d:1043: undefined reference to `retStyle(TypeFunction*)' /home/seb/dlang/dmd/src/ddmd/dsymbolsem.d:1097: undefined reference to `retStyle(TypeFunction*)' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(expression.o):(.data.rel.ro+0x40): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(func.o):(.data.rel.ro+0x28): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(mars.o):(.data.rel.ro+0x20): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(mtype.o):(.data.rel.ro+0x38): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(objc.o):(.data.rel.ro+0x60): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(objc_5ba_3c6.o): In function `_D4ddmd4objc9Supported6__ctorMFZCQBfQBdQBb': /home/seb/dlang/dmd/src/ddmd/objc.d:185: undefined reference to `objc_initSymbols()' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(statement.o):(.data.rel.ro+0x30): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(statementsem.o):(.data.rel.ro+0xd0): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(statementsem_632_9d9.o): In function `StatementSemanticVisitor::visit(AsmStatement*)': /home/seb/dlang/dmd/src/ddmd/statementsem.d:3923: undefined reference to `asmSemantic(AsmStatement*, Scope*)' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(typinf.o):(.data.rel.ro+0x48): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(aggregate.o):(.data.rel.ro+0x18): undefined reference to `_D4ddmd9gluelayer12__ModuleInfoZ' /tmp/.dub/build/dmd-~dub-frontend/library-debug-linux.posix-x86_64-dmd_2077-A550EF4C39A32552F8FE470A957BC323/libdmd_frontend.a(typinf_680_468.o): In function `genTypeInfo(Type*, Scope*)': /home/seb/dlang/dmd/src/ddmd/typinf.d:67: undefined reference to `toObjFile(Dsymbol*, bool)'

I see. I think we can do some refactoring later to remove these dependencies if we want to.

BTW, I think lib.d is for generating libraries, which I don't think we need.

jacob-carlborg · 2017-12-14T09:43:14Z

src/ddmd/frontend.d

+*/
+void initDMD()
+{
+    import ddmd.globals : global;


This is not used as far as I can see.

jacob-carlborg · 2017-12-14T09:47:20Z

test/dub_package/frontend.d

+    import ddmd.globals : global;
+
+    global._init;
+    global.params.isLinux = 1;


Do we need to worry about this when the tests are also run on macOS?

jacob-carlborg · 2017-12-14T16:35:35Z

LGTM 👌.

andralex

For an initial release, looks great. cc @RazvanN7

andralex · 2017-12-15T14:25:25Z

dub.sdl

+  versions "NoMain"
+  sourcePaths
+
+  sourceFiles \


This list will need to be updated every time a source file is added or removed. Is there a simple way to automate it?

One way is to move every file that is part of the Dub package to its own directory, like frontend, then the whole directory can be included with sourcePaths.

DUB also supports excludedSourceFiles for removing files from a sourcePaths set

Give it a try. Seems to be simple enough, though it would have been easier with a better layout of DMD (see the exclude file globs) and I don't know how fast the globbing is implemented in DUB (though it's a handful of files)...

If you want to cleanup the house, some ideas:

move everything related to the IR -> dmd.ir

move everything related to reading & writing object files src/dmd/{scan,lib}{elfmach,mscoff,omf}.d -> dmd.obj

group other files into folders too, e.g. the dmd.parser or dmd.visitor

wilzbach · 2017-12-19T09:05:19Z

For an initial release,

So I finally got Travis to pass :)
I had to add a small configuration file searcher for LDC to get Travis to pass.
I excluded GDC from checking the dub package for now, because there were too many errors and using Phobos fully is very convenient. Also IIRC a new release for GDC is scheduled to happen sometime in early 2018, so by the time this DUB package is fully usable (i.e. we have proper semantic versioning and have worked out all the other issues), using DMD as a library via DUB with GDC won't be a problem either. From what I can tell are these examples intended to be showcases anyhow and this PR changes the status quo from not usable to compiling & working with a simple example.

Finally the "simple" frontend example now has more than 150 lines, so in a follow-up PR we should try to factor out common logic to dmd.frontend (CC @RazvanN7).

wilzbach · 2017-12-21T08:22:30Z

@andralex @jacob-carlborg @RazvanN7 (or other) okay to move forward with this as an initial version? I would like to look into @joakim-noah's report that we can't due a full semantic on Phobos yet and also start to build stuff on top of this ;-)

jacob-carlborg · 2017-12-21T10:41:33Z

Yes, please move forward 👌.

jacob-carlborg · 2017-12-21T10:43:20Z

Auto-merge toggled on

RazvanN7

Other than some minor comments it looks good. The next step should be to expose more semantic methods in a way that is easy to use, for example: the one which I find very important is the search method which does symbol resolution.

RazvanN7 · 2017-12-21T10:45:54Z

test/dub_package/frontend.d

+import std.stdio;
+
+// add import paths
+void addImports(T)(T path)


Why isn't this in frontend.d? (src/dmd/frontend.d)

RazvanN7 · 2017-12-21T10:46:24Z

test/dub_package/frontend.d

+}
+
+// finds a dmd.conf and parses it for import paths
+auto findImportPaths()


Why isn't this in frontend.d ?

RazvanN7 · 2017-12-21T10:46:45Z

test/dub_package/frontend.d

+        }
+    });
+
+    void semantic()


This should certainly be in frontend.d and we could call it fullSemanticAnalysis or something along these terms.

Unless there's a reason to not run the full semantic analysis I don't think the full prefix is necessary. I hope that we can keep the three phases an implementation detail.

I'm not sure this is possible. As a tool developer you may want to visit the AST while it is in a certain state. Given the fact that the semantic methods modify the AST quite a lot you might want to take a look at it before a certain semantic pass is done. For example: enums are evaluated at compile time (during semantic3) ; in order to do those modifications the semantic3 stage alters the AST; as a tool developer I may want to do something with the original AST which is not longer possible given that semantic3 has modified it.

Hehe that's exactly why I didn't want to push this into frontend.d for now ;-)

That's not a problem. You have the individual semantic passes, but if you don't care about that you can just call FullSemanticAnalysys or some other name that you find suited.

Please let leave it as is and continue improve it after this is merged.

wilzbach · 2017-12-21T11:06:22Z

The next step should be to expose more semantic methods in a way that is easy to use, for example: the one which I find very important is the search method which does symbol resolution.

Yes they should be (I think I mentioned this a couple of times), but for now I didn't want to push anything to frontend.d as I didn't want to stall this PR unnecessarily with a discussion of the exposed user API (@RazvanN7 how about having a chat in the next days regarding this?)
Also, once this is in, we can trivially refactor the code, as we will have at least one CI checking it :)

RazvanN7 · 2017-12-21T11:07:36Z

@wilzbach Sure thing. I was just suggesting the next step after this PR is merged.

wilzbach · 2017-12-21T15:41:41Z

Why isn't this in frontend.d? (src/dmd/frontend.d)
I was just suggesting the next step after this PR is merged.

Yes, let's continue the discussion at #7485

wilzbach requested a review from WalterBright as a code owner December 12, 2017 03:17

dlang-bot added the Review:WIP Work In Progress - not ready for review or pulling label Dec 12, 2017

wilzbach commented Dec 12, 2017

View reviewed changes

This was referenced Dec 12, 2017

Start testing the DMD DUB package on Travis #7415

Merged

Integrate ASTBase visitor with the compiler visitor #7397

Merged

wilzbach force-pushed the dub-frontend branch from e476081 to 5a7e4e7 Compare December 14, 2017 01:02

wilzbach requested review from CyberShadow and MartinNowak as code owners December 14, 2017 01:02

wilzbach force-pushed the dub-frontend branch 2 times, most recently from a908012 to 78a97fb Compare December 14, 2017 01:18

wilzbach force-pushed the dub-frontend branch 2 times, most recently from 197f8a9 to c054b31 Compare December 14, 2017 01:31

wilzbach commented Dec 14, 2017

View reviewed changes

wilzbach force-pushed the dub-frontend branch from c054b31 to 211ec51 Compare December 14, 2017 01:34

joakim-noah mentioned this pull request Dec 14, 2017

Add a global convenience package file dlang/phobos#5916

Merged

jacob-carlborg suggested changes Dec 14, 2017

View reviewed changes

wilzbach force-pushed the dub-frontend branch from 211ec51 to c41a200 Compare December 14, 2017 08:41

jacob-carlborg reviewed Dec 14, 2017

View reviewed changes

jacob-carlborg suggested changes Dec 14, 2017

View reviewed changes

wilzbach force-pushed the dub-frontend branch from c41a200 to 682e3f7 Compare December 14, 2017 10:08

jacob-carlborg approved these changes Dec 14, 2017

View reviewed changes

wilzbach force-pushed the dub-frontend branch from 682e3f7 to 0c91dab Compare December 15, 2017 05:55

andralex approved these changes Dec 15, 2017

View reviewed changes

wilzbach force-pushed the dub-frontend branch from 0c91dab to 6c18da4 Compare December 15, 2017 20:33

wilzbach force-pushed the dub-frontend branch from 1a86af1 to ffb1b87 Compare December 19, 2017 05:42

wilzbach removed the Review:Needs Work label Dec 19, 2017

wilzbach added 4 commits December 19, 2017 06:44

Add allocmemory to Mem (GC-version)

cbd0d27

Expose D frontend via DUB

b203430

Test all DUB examples on Travis

84752b6

Ignore all executables within test/dub_packages

2f0b835

wilzbach force-pushed the dub-frontend branch 2 times, most recently from 0a0ce99 to 3799247 Compare December 19, 2017 06:37

wilzbach added 2 commits December 19, 2017 08:41

Add frontend module and example

e88073d

Use sourcePaths and excludeSourceFiles

bb0161d

wilzbach force-pushed the dub-frontend branch 6 times, most recently from 6b4ad57 to 94c6525 Compare December 19, 2017 08:21

Don't run DUB frontend examples with GDC

711f365

wilzbach force-pushed the dub-frontend branch from 94c6525 to 711f365 Compare December 19, 2017 08:21

wilzbach added the Review:Blocking Other Work review and pulling should be a priority label Dec 21, 2017

RazvanN7 reviewed Dec 21, 2017

View reviewed changes

jacob-carlborg merged commit 703e48e into dlang:master Dec 21, 2017

wilzbach mentioned this pull request Dec 21, 2017

Move frontend utility functions from the DUB package to dmd.frontend #7485

Merged

wilzbach deleted the dub-frontend branch December 21, 2017 15:41

		@@ -1,6 +1,13 @@
		# Ignore all binary files (files without an extension)


		If you want to see the log output or want to pass additional options, use `--single`:

		dub --single -v lexer.d

Uh oh!

Conversation

wilzbach commented Dec 12, 2017

Uh oh!

dlang-bot commented Dec 12, 2017

Bugzilla references

Uh oh!

wilzbach commented Dec 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob-carlborg Dec 12, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilzbach commented Dec 14, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PetarKirov Dec 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilzbach commented Dec 14, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Remove libelf.d

Remove gluelayer.d

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob-carlborg commented Dec 14, 2017

Uh oh!

andralex left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob-carlborg Dec 12, 2017 •

edited

Loading

PetarKirov Dec 16, 2017 •

edited

Loading

Remove `gluelayer.d`

jacob-carlborg Dec 15, 2017 •

edited

Loading

wilzbach Dec 16, 2017 •

edited

Loading

jacob-carlborg Dec 21, 2017 •

edited

Loading

RazvanN7 Dec 21, 2017 •

edited

Loading