[Issue 19479] Garbage .init in string mixins in static foreach in mixin templates
https://issues.dlang.org/show_bug.cgi?id=19479 Dlang Bot changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #10767 "fix Issue 19479 - Garbage .init in string mixins in static foreach in mixin templates" was merged into master: - 02ddfe07acc0c0cee4cc8f5aa30210d9ad235e92 by Iain Buclaw: fix Issue 19479 - Garbage .init in string mixins in static foreach in mixin templates The problem was that the mixin was being omitted from the codegen during the conversion from StaticForeachDeclaration to a Statement. The first issue with `toStatement` is that it is visiting all members in the StaticForeachDeclaration's `decl`, whereas the semantically compiled list of Dsymbols is instead found in `cache`. This is what caused the CompileDeclaration to be omitted. The second issue with `toStatement` is that converting an already compiled StaticForeachDeclaration into a new StaticForeachStatement results in `makeTupleForeach` being called twice for the same StaticForeach symbol. There is no need to create a new StaticForeachStatement, simply the unrolling of all members is enough. https://github.com/dlang/dmd/pull/10767 --
[Issue 20362] dmd fails to infer scope parameter for delegate
https://issues.dlang.org/show_bug.cgi?id=20362 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #10764 "Fix issue 20362 - always infer scope for lambdas" was merged into master: - ac32a33c1dfdeec2b24dda175cbb1fe87778c012 by Atila Neves: Fix issue 20362 - always infer scope for lambdas Before, scope was only inferred if -preview=dip1000 was used, now it always is. https://github.com/dlang/dmd/pull/10764 --
[Issue 20547] Wrong error message when trying to "new" an associative array
https://issues.dlang.org/show_bug.cgi?id=20547 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @benjones created dlang/dmd pull request #10768 "fix issue 20547, improve error messages for malformed new expressions" fixing this issue: - fix issue 20547, error messages for bad new expressions https://github.com/dlang/dmd/pull/10768 --
[Issue 15322] version(Unicode) should affect only default aliases
https://issues.dlang.org/show_bug.cgi?id=15322 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/druntime pull request #2928 "Fix Issue 15322 - Correct versioning PENUM_PAGE_FILE_CALLBACK" was merged into master: - 515500355fde5d1611e751163f0c79bfdd78f19c by Asakusa Yakumo: Fix Issue 15322 - Correct versioning PENUM_PAGE_FILE_CALLBACK According to [Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-enumpagefilesw), `EnumPageFilesW` always taking a `PENUM_PAGE_FILE_CALLBACKW` parameter. While before the correction, when version `Unicode` is not defined, `EnumPageFilesW` will be declared to take a `PENUM_PAGE_FILE_CALLBACKW`. https://github.com/dlang/druntime/pull/2928 --
[Issue 16658] Win32API: default IE ver. set to 4.0 is too old
https://issues.dlang.org/show_bug.cgi?id=16658 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/druntime pull request #2929 "Fix Issue 16658: Default IE version set to 6.0" was merged into master: - 14df4d4bc0c40b5ebe2aac33798840a98596575a by Asakusa Yakumo: Fix Issue 16658: Default IE version set to 6.0 IE 4 it too old. As it only supports up to WinNT 4.0, it's not available on WinXP or even Win2k. This leads to a mismatch with the default `_WIN32_WINNT = 0x500` (WinXP) value. Make the default IE version set to 6.0 could make more APIs available at default. Also, DMD now supports only `Windows 7 or later, 32 or 64 bit` and Windows 7 has reached End Of Life on 14 January 2020, it could reasonably set default value to: `_WIN32_WINNT = 0x601` and `_WIN32_IE = 0x800`. But this topic should be discussed in another PR. https://github.com/dlang/druntime/pull/2929 --
[Issue 19479] Garbage .init in string mixins in static foreach in mixin templates
https://issues.dlang.org/show_bug.cgi?id=19479 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @ibuclaw created dlang/dmd pull request #10767 "fix Issue 19479 - Garbage .init in string mixins in static foreach in mixin templates" fixing this issue: - fix Issue 19479 - Garbage .init in string mixins in static foreach in mixin templates The problem was that the mixin was being omitted from the codegen during the conversion from StaticForeachDeclaration to a Statement. The first issue with `toStatement` is that it is visiting all members in the StaticForeachDeclaration's `decl`, whereas the semantically compiled list of Dsymbols is instead found in `cache`. This is what caused the CompileDeclaration to be omitted. The second issue with `toStatement` is that converting an already compiled StaticForeachDeclaration into a new StaticForeachStatement results in `makeTupleForeach` being called twice for the same StaticForeach symbol. There is no need to create a new StaticForeachStatement, simply the unrolling of all members is enough. https://github.com/dlang/dmd/pull/10767 --
[Issue 20563] New: module conflicts with package confusing error message
https://issues.dlang.org/show_bug.cgi?id=20563 Issue ID: 20563 Summary: module conflicts with package confusing error message Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: diagnostic Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com If I declare two packages with the same name accidentally, then the compiler tells me there's an error, but doesn't tell me where the conflict is. In some cases, this might be obvious, but in others it's not For example: - foo/package.d module foo; - bar/package.d module foo; - dmd foo/package.d bar/package.d bar/package.d(1): Error: module foo from file bar/package.d conflicts with package name foo This error is OK, since I realize that bar/package.d shouldn't be foo, and I can correct it. However, if I change the order of compilation: dmd bar/package.d foo/package.d foo/package.d(1): Error: module foo from file foo/package.d conflicts with package name foo This error is super-confusing, because of COURSE I want foo/package.d to be package module foo, how does it conflict with the package foo? The error should specify where the previous definition of module-package foo is. I looked at the code for this, the relevant lines are here: https://github.com/dlang/dmd/blob/ee19c0b5c0465dfe158bb20042988a32dfdb/src/dmd/dmodule.d#L1081-L1094 Looking at that code, it is telling me there's an error because the package was already resolved to be a package or a module. If I look through the code, I can't find any place where it's set to a package_, (there is a function resolvePKGUnknown, but it's never called, I'm assuming it may have been called at some point in the past) so I assume that this can only happen with two package modules that are competing for the right one. Note that if I just declare a foo.d with module foo, then I get a similar error: foo.d(1): Error: module foo from file foo.d conflicts with package name foo Again, if it said something like: bar/package.d(1): previously declared here then I can instantly see the problem. We might also want to change the message to clarify it's not conflicting with a package, but a declaration of a package module (which must be true since it's never declared a package_ type). --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 --- Comment #7 from JR --- (In reply to Seb from comment #6) > This probably doesn't help you, but as it's easy to test: > Did you try this with 2.090 as well? There was a regression with the change > to build.d that omitted the -O flag on Windows. This has been addressed > since. I hadn't, so I tested it now with current master (v2.090.0-beta.1-118-g8fc81f40d) and I get the same results. Further I tried a 64-bit compiler (with digger build --model=64), and it runs out of memory too. I've also retried the bisection several times hoping it would land on a different commit, but I get the same one. I even made the tester script test each build three times so as to not miss something due to transient successes. The only thing that works so far is to copy/paste the build command `dub build -v` prints and run it with -lowmem added. Curiously dub with -lowmem DFLAGS does not seem to work. Manually calling dmd with the same command does. --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #6 from Seb --- This probably doesn't help you, but as it's easy to test: Did you try this with 2.090 as well? There was a regression with the change to build.d that omitted the -O flag on Windows. This has been addressed since. --
[Issue 20362] dmd fails to infer scope parameter for delegate
https://issues.dlang.org/show_bug.cgi?id=20362 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @atilaneves created dlang/dmd pull request #10764 "Fix issue 20362 - always infer scope for lambdas" fixing this issue: - Fix issue 20362 - always infer scope for lambdas Before, scope was only inferred if -preview=dip1000 was used, now it always is. https://github.com/dlang/dmd/pull/10764 --
[Issue 20362] dmd fails to infer scope parameter for delegate
https://issues.dlang.org/show_bug.cgi?id=20362 --- Comment #2 from Dlang Bot --- @atilaneves updated dlang/dmd pull request #10506 "WIP (do not merge): Make `in` mean `scope const` in DIP1000" mentioning this issue: - Non hacky way to get around issue 20362 https://github.com/dlang/dmd/pull/10506 --
[Issue 20362] dmd fails to infer scope parameter for delegate
https://issues.dlang.org/show_bug.cgi?id=20362 --- Comment #1 from Atila Neves --- Note: the code was taken out of context, but the reason it's *really* important is that it occurs in Throwable.toString --
[Issue 16149] foreach_reverse can't handle index variable of type int
https://issues.dlang.org/show_bug.cgi?id=16149 moonlightsenti...@disroot.org changed: What|Removed |Added Status|NEW |RESOLVED CC||moonlightsentinel@disroot.o ||rg Resolution|--- |FIXED --- Comment #8 from moonlightsenti...@disroot.org --- The code works and yields an appropriate warning concerning int -> size_t for both loops --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 --- Comment #5 from JR --- Ignore that, it does seem to be doing something now. It still runs out of memory though, will experiment. Apologies for the noise. --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 --- Comment #4 from JR --- (In reply to moonlightsentinel from comment #3) > > I see. Is there a point in retrying the bisection? > > Maybe if you could exactly identify a change that increased the memory > consumption *a lot*. Then we could try to improve that specific segement to > use less memory. But I would expect it to be a more gradual increase > scattered over many small changes. > > > -lowmem works and I want to use it, but it doesn't work with dub, which I > > rely on for dependencies > > Not a dub expert but you could add -lowmem using the dflags configuration in > dub.(json|sdl) IIRC. This was one of the topics of https://forum.dlang.org/post/ycfikiktizuifuisx...@forum.dlang.org; even if defined in dflags dub doesn't pass -lowmem to dmd. The flag is silently ignored. --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 --- Comment #3 from moonlightsenti...@disroot.org --- > I see. Is there a point in retrying the bisection? Maybe if you could exactly identify a change that increased the memory consumption *a lot*. Then we could try to improve that specific segement to use less memory. But I would expect it to be a more gradual increase scattered over many small changes. > -lowmem works and I want to use it, but it doesn't work with dub, which I > rely on for dependencies Not a dub expert but you could add -lowmem using the dflags configuration in dub.(json|sdl) IIRC. --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 --- Comment #2 from JR --- (In reply to moonlightsentinel from comment #1) > That linker parameter was already present in win32.mak, the PR just moved it > to build.d. That bisection seems like a false positive. > > An OutOfMemoryError usually signals a failure when allocating memory> - not stack memory. Did you try to compile your project using > -lowmem (which enables the GC for DMD)? I see. Is there a point in retrying the bisection? -lowmem works and I want to use it, but it doesn't work with dub, which I rely on for dependencies. https://forum.dlang.org/post/ycfikiktizuifuisx...@forum.dlang.org seems promising but it's still some time before it will be in a downloadable release. --
[Issue 20562] [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg --- Comment #1 from moonlightsenti...@disroot.org --- That linker parameter was already present in win32.mak, the PR just moved it to build.d. That bisection seems like a false positive. An OutOfMemoryError usually signals a failure when allocating - not stack memory. Did you try to compile your project using -lowmem (which enables the GC for DMD)? --
[Issue 20562] New: [dmd] Memory allocation failed (ERROR: This is a compiler bug)
https://issues.dlang.org/show_bug.cgi?id=20562 Issue ID: 20562 Summary: [dmd] Memory allocation failed (ERROR: This is a compiler bug) Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: zor...@gmail.com After updating to 2.088.1 from 2.087.1, my project no longer compiles with dmd under Windows and just throws an OutOfMemoryError. I bisected it to https://github.com/dlang/dmd/pull/10446, which adds a stack size linker parameter to dmd's compilation, and thus breaks mine. > diff --git a/src/build.d b/src/build.d > index 8b5d59373..592ceb8a8 100755 > --- a/src/build.d > +++ b/src/build.d > @@ -361,13 +361,16 @@ alias dmdExe = memoize!(function(string targetSuffix, > string[] extraFlags...) > target = env["DMD_PATH"] ~ targetSuffix; > msg = "(DC) DMD%s %-(%s, %)".format(targetSuffix, dmdSources.map!(e > => e.baseName).array); > deps = [versionFile, sysconfDirFile, lexer, backend]; > +string[] platformArgs; > +version (Windows) > +platformArgs = ["-L/STACK:8388608"]; > command = [ > env["HOST_DMD_RUN"], > "-of" ~ target, > "-vtls", > "-J"~env["G"], > "-J../res", > -].chain(extraFlags).chain(flags["DFLAGS"], sources).array; > +].chain(extraFlags, platformArgs, flags["DFLAGS"], sources).array; > } > return new DependencyRef(dep); > }); I don't know enough. Assuming it's there for a reason and can't be reverted, can we at least increase the size? Or is there some other way for me to be able to keep using dmd? To test (assuming Windows): > git clone https://github.com/zorael/kameloso > cd kameloso > dub build -c vanilla # lightest build C:\Temp\kameloso>dub build -c vanilla Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64. lu:core 0.1.2: target for configuration "library" is up to date. lu:meld 0.1.2: target for configuration "library" is up to date. dialect 0.3.2: target for configuration "library" is up to date. lu 0.1.2: target for configuration "library" is up to date. kameloso 1.5.0+commit.15.g588f6e55: building configuration "vanilla"... --- ERROR: This is a compiler bug. Please report it via https://issues.dlang.org/enter_bug.cgi with, preferably, a reduced, reproducible example and the information below. DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the reduction. --- DMD v2.090.0-dirty predefs WithAdminPlugin WithAutomodePlugin WithBashQuotesPlugin WithChanQueriesService WithChatbotPlugin WithConnectService WithCTCPService WithHelpPlugin WithNotesPlugin WithOnelinersPlugin WithPersistenceService WithPipelinePlugin WithPrinterPlugin WithQuotesPlugin WithSedReplacePlugin WithSeenPlugin WithWebtitlesPlugin WithPlugins Have_kameloso Have_dialect Have_lu FlagAsUpdated Have_lu_core Have_lu_meld DigitalMars Windows CRuntime_Microsoft CppRuntime_Microsoft LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 Win64 D_LP64 assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binaryC:\D\dmd2\windows\bin\dmd.exe version v2.090.0-dirty configC:\D\dmd2\windows\bin\sc.ini DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import -L/OPT:NOICF --- core.exception.OutOfMemoryError@src\core\exception.d(647): Memory allocation failed > dub remove dialect --version=* > dub remove lu --version=* Bisection results: digger: Finding shortest path between 77f556acec92e295ac04e96f800f6d81a8b53ec0 and 2ca17849f4ce2585cb288026241337425385a590... digger: 0 commits (about 0 tests) remaining. digger: 2ca17849f4ce2585cb288026241337425385a590 is the first bad commit commit 2ca17849f4ce2585cb288026241337425385a590 Author: The Dlang Bot Date: Fri Oct 4 01:17:22 2019 +0200 dmd: Merge pull request #10446 from marler8997/compileDmdBuildD https://github.com/dlang/dmd/pull/10446 Compile dmd exe in build.d merged-on-behalf-of: Nicholas Wilson --
