[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #8 from Jonathan M Davis  ---
Well, regardless of what's actually causing the problem, I completely agree
that it should be fixed. However, not being a compiler dev, I have no clue how
likely that is to be quick or easy.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #7 from Manu  ---
Orly? Doesn't happen for you? That's even worse.

Just the presence of the declaration shouldn't result in a link error.
You can declare all the undefined functions you like, you don't get link errors
unless there is a reference to them that the linker tries (and can't) resolve.
I don't understand what reference there could possibly be to Zip!().init, even
if it was generated and emit to the symbol table when it was instantiated by
CTFE.

Your hunch that it's emit into some sort of template-instantiation namespace
rather than into a module is probably on the money. It smells like the problem
could be tangled in that complexity... but at the end of the day, I just can't
imagine where the reference is that the linker could be upset about.

Anyway, this was discovered by a colleague at Blizzard who's exploring D. It
would certainly be reassuring if we could fix it promptly.

--

[Issue 18493] [betterC] Can't use aggregated type with postblit

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18493

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull
 CC||slavo5...@yahoo.com

--- Comment #4 from Mike Franklin  ---
A PR has been submitted to remove generation of the try-catch if the postblit
is `nothrow`:  https://github.com/dlang/dmd/pull/8184

I don't consider this a complete fix to this issue, but if it is accepted, it
will allow one to attribute their postblit with `nothrow` to avoid the error in
-betterC.

I'm pondering a more thorough solution for -betterC, and intend to tackle that
as another PR.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #6 from Jonathan M Davis  ---
(In reply to Manu from comment #5)
> I think you've missed my point, there is NO REFERENCE to Zip!().init in
> main.d, at least, there shouldn't be... so why the link error?
> Where is the reference coming from?

You imported test.di. test.di references Zip!().init, and it references it when
creating the function that you're calling from main.d. So, it's being used when
generating main.d even if main.d doesn't use it directly. I'd guess that the
problem relates to that. It's likely inserting the symbol when it imports
test.di. I don't see what else the problem could be. Also, remember that you're
actually generating template instantations with that code. It's not just
referencing existing code like it would with a normal function. Template
instantations don't live with the module that they come from in the same way
that other functions do, because they can't, since they're not compiled with
the module. I'd guess that that's part of the problem and that it results in
the template instantiations being inserted into the resultant binary.

Curiously, if I compile your example on FreeBSD (with clang as the C/C++
compiler, though I think that it's actually using GNU's linker), I only get an
undefined reference for `_D4test9test_funcFiiZv', so it appears that the
problem with Zip may be system-dependent. Maybe one linker ignores it because
it isn't used directly in main.d, and the other doesn't? I don't know.
Certainly, the fact that it appears to differ from system to system doesn't
give me a warm, fuzzy feeling.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #5 from Manu  ---
> dmd -m64 main.d

Emits:

  main.obj : error LNK2019: unresolved external symbol _D4test9test_funcFiiZv
referenced in function _Dmain  (expected)
  main.obj : error LNK2001: unresolved external symbol
_D3std5range__T3ZipTAAyaTQfZQn6__initZ(WTF?)


I think you've missed my point, there is NO REFERENCE to Zip!().init in main.d,
at least, there shouldn't be... so why the link error?
Where is the reference coming from?

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
If the .di file is being used, then the code that's importing it would expect
the symbol, but if the object file is then generated from the .d file, the
symbol isn't there, thus I would expect a linker error. AFAIK, the only way
around that would be if the compiler were smart enough to only use the symbol
for as long as necessary to do the CTFE call, because it's only used during
CTFE, and I don't think that it's that smart, much as I think that we can all
agree that we want it to be that smart.

I'd suggest that you provide the actual compilation commands that you're using
so that it's 100% clear how to reproduce what you're doing.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #3 from Manu  ---
Well in this case, the symbol is emit in a .di file, which means it's never
written to any object file; hence the unresolved external...

But that's actually kind-of irrelevant. The big question I have here is, where
is the link error coming from?! Why is there a reference in main.obj to
Zip!(...)'s init value? Where could that symbol reference possibly be coming
from? There's no runtime calls to zip().

I don't understand how the link error is even emerging, because there should be
nothing making such a reference.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #2 from hst...@quickfur.ath.cx ---
P.S. and the `if (__ctfe)` hack I use only saves on executable size, it doesn't
suppress the symbol itself from appearing in the object file, so it's probably
not good enough for your use case.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

--- Comment #1 from hst...@quickfur.ath.cx ---
AIUI, all template functions that are instantiated will end up in the object
file, even if they are only used during CTFE (i.e. the instantiation is
triggered by CTFE but not anywhere else).  This is a problem that's been
bothering me too, which has led me to insert `if (__ctfe)` blocks into my CTFE
functions.  But if you're using Phobos functions, then you're out of luck.

I agree that the compiler should have some way to track whether a particular
template function / instantiation / etc., is only referenced by CTFE code, so
that said functions are omitted from the object file when emitting code. 
Possibly something like a boolean flag in the template symbol to indicate
whether the symbol is referenced by runtime constructs.

I suspect, though, that this is far from trivial to implement, because code
that gets run by CTFE is essentially just one step away from being emitted as
object code, and for all intents and purposes is considered as "runtime" code
by many parts of the compiler.  So you get tricky things like whether a
function called by a CTFE function should be marked as CTFE-only or should be
included in the object file (since that function call would have been resolved
before the CTFE engine even sees it, so it would already have been considered
as "runtime", even if in actuality it will only ever be called from CTFE).

Still, it's a nice-to-have.

--

[Issue 18774] meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 18774] New: meta used in .di files causes link errors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18774

  Issue ID: 18774
   Summary: meta used in .di files causes link errors
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

We produce a function prototype in a .di file using some meta

test.di
---
module test;

template Test()
{
import std.range, std.algorithm;
enum Test = "void test_func(" ~
  zip(["int","int"], ["a","b"])
.map!(tuple => tuple[0] ~ " " ~ tuple[1])
.reduce!((a, b) => a ~ ", " ~ b) ~
");";
}
mixin(Test!()); // <- Mixes in: void test_func(int a, int b);
---


main.d
--
import test;

int main()
{
test_func(1, 2);

return 0;
}
--


I expect compiling this example to result in a single link error to the
unresolved external test_func().
But we also see "error LNK2001: unresolved external symbol
_D3std5range__T3ZipTAAyaTQfZQn6__initZ"

Calling zip() at CTFE results in an additional unexpected link error.
Using a function in CTFE this way shouldn't affect the symbol table, or add any
additional link references.

--

[Issue 18773] New: Constraints on buffer re-use for std.zlib should be documented.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18773

  Issue ID: 18773
   Summary: Constraints on buffer re-use for std.zlib should be
documented.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: briancsch...@gmail.com

The Compress and UnCompress classes have undocumented restrictions on when the
buffers passed to their `compress` and `uncompress` methods can be re-used.
This needs to be fixed so that people are not accidentally creating or reading
corrupted data.

--

[Issue 18760] theAllocator should hold a reference to the allocator that it uses

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18760

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/4126f928270570c9149a6412acde16f16506fd39
Merge pull request #6449 from edi33416/fix_thread_alloc

Fix Issue 18760 - theAllocator dangling reference bug

--

[Issue 18760] theAllocator should hold a reference to the allocator that it uses

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18760

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15574] wrong order of linker arguments

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15574

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15574] wrong order of linker arguments

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15574

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/fbaeeaee1cac009d9f7157b7d63ea22dee1d3b0e
Fix issue 15574 - wrong order of link arguments

This essentially places *.a arguments before the -l and -L switches in
the linker command line.

This allows to link applications that link against a static archive *.a
that depends on -l lib switches.
Such dependency scheme is typical of the following situation:
  - have a D package that contains binding to a C library.
  - this D package is itself built as a static library (libdpackage.a).
  - the C library is built in the same build process as a static library
(pathtoClib/libclib.a)
  - dmd is invoked in the following way:

  $ dmd ... libdpackage.a -L-LpathtoClib -L-lclib

Currently dmd reorders arguments and places *.a after -l linker switches
which causes link errors if the -l points to a static library.

This is especially useful with Dub, which can be configured to probe for
the C library, and build it as a static lib if not found system-wide.
In both cases, the C library is provided with "libs" json entry.

So this is not about keeping relative order of linker arguments, it is
about providing an order of linker arguments that is more sound than
the current one.

https://github.com/dlang/dmd/commit/10c8fa536879536b4fa339d8325b7a3ab0990d51
add test for issue 15574

https://github.com/dlang/dmd/commit/6371942b1bf26dc6c65cc7e0668bc82e1974c18d
Merge pull request #8172 from rtbo/linker_arg_order

Fix issue 15574 - wrong order of link arguments
merged-on-behalf-of: Razvan Nitu 

--

[Issue 5227] X ^^ FP at compile-time

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5227

--- Comment #18 from Manu  ---
Yay! 8 years in the making. This must be a very fine brew! :P

--

[Issue 18772] [ICE] Internal error: dmd\backend\cgcod.c 607 no optimizations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18772

ponce  changed:

   What|Removed |Added

Summary|[ICE] Internal error:   |[ICE] Internal error:
   |dmd\backend\cgcod.c 607 |dmd\backend\cgcod.c 607 no
   ||optimizations

--

[Issue 18772] [ICE] Internal error: dmd\backend\cgcod.c 607

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18772

--- Comment #1 from ponce  ---
Successfully reproduced using:

dmd_2.079.1 (latest)
dmd_2.074.1
dmd_2.070.0 (2 years ago)

--

[Issue 18772] New: [ICE] Internal error: dmd\backend\cgcod.c 607

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18772

  Issue ID: 18772
   Summary: [ICE] Internal error: dmd\backend\cgcod.c 607
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

Please consider the following program:


 main.d --

float fun(cfloat z)
{
return z.re;
}

void main()
{
cfloat[1] A;
float[1] B;
int i = 0;
double C = fun(A[i] * B[i]);  
}



Build it with DMD D Compiler v2.079.0 in 64-bit


$ rdmd -m32 main.d

(Builds and run without problem)


$ rdmd -m64 main.d

Internal error: dmd\backend\cgcod.c 607

--

[Issue 12734] Template cannot deduce E[] from typeof(null)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12734

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #2 from ag0aep6g  ---
(In reply to Andrej Mitrovic from comment #0)
> -
> void take1(int[] buffer) { }
> void take2(E)(E[] buffer) { }
> 
> void main()
> {
> take1(null);  // ok
> take2(null);  // fail
> }
> -
> 
> I'm not sure what 'E' would be deduced to with a typeof(null) though. Maybe
> just a 'void'? Or a 'void*'? It's hard to tell, but the above forces us to
> create overloads for the sake of supporting null.

Works since 2.067.1, with E = void. Closing as worksforme.
https://run.dlang.io/is/QhvCjh

--

[Issue 1807] ENHANCEMENT: Let IFTI "see through" templates to simple aliases

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1807

--- Comment #7 from ag0aep6g  ---
*** Issue 10884 has been marked as a duplicate of this issue. ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10884

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #5 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 1807 ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10884

ag0aep6g  changed:

   What|Removed |Added

 CC||atila.ne...@gmail.com

--- Comment #4 from ag0aep6g  ---
*** Issue 11452 has been marked as a duplicate of this issue. ***

--

[Issue 11452] IFTI failure for aliased static array parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11452

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #3 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 10884 ***

--

[Issue 13090] Type inferring fails at function parameters with parameterized alias

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13090

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #2 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 10884 ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10884

ag0aep6g  changed:

   What|Removed |Added

 CC||ncras...@gmail.com

--- Comment #3 from ag0aep6g  ---
*** Issue 13090 has been marked as a duplicate of this issue. ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10884

ag0aep6g  changed:

   What|Removed |Added

 CC||sky.13th...@gmail.com

--- Comment #2 from ag0aep6g  ---
*** Issue 16486 has been marked as a duplicate of this issue. ***

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 10884 ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10884

ag0aep6g  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #1 from ag0aep6g  ---
*** Issue 18769 has been marked as a duplicate of this issue. ***

--

[Issue 18769] Cannot infer template parameters for aliased types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18769

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 10884 ***

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16465

ag0aep6g  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #9 from ag0aep6g  ---
(In reply to Sky Thirteenth from comment #8)
> (In reply to b2.temp from comment #7)
> > (In reply to Sky Thirteenth from comment #6)
> > > (In reply to b2.temp from comment #5)
> > > > I confirm the misunderstanding. If you permit I would suggest you to 
> > > > close
> > > > this one but to open a new issue using your second example. The first 
> > > > one
> > > > really represented issue 6082. The second is perfectly clear.
[...]
> Here the new one https://issues.dlang.org/show_bug.cgi?id=16486

Since the issue has been moved, I'm closing this one as invalid.

--

[Issue 18771] New: Identical overload sets in different modules have different identities

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18771

  Issue ID: 18771
   Summary: Identical overload sets in different modules have
different identities
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD v2.079.0:

---
module a;
void foo(int){}
---

---
module b;
void foo(string){}
---

---
module c;
import a, b;
alias fooC=foo;
---

---
module d;
import a, b;
alias fooD=foo;
---

---
module e;
import c, d;
static assert(__traits(isSame, fooC, fooD)); // fail
---

The code should compile.

--

[Issue 18584] Undefined identifier when not specifying 'this'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18584

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18584] Undefined identifier when not specifying 'this'

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18584

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/814b822011002fe89434f195597ed6a20042ce88
Fix Issue 18584 - Undefined identifier when not specifying 'this'

https://github.com/dlang/dmd/commit/b4d5005db0fd3581789d8a0942583f7c13efbc82
Merge pull request #8159 from RazvanN7/Issue_18584

Fix Issue 18584 - Undefined identifier when not specifying 'this'
merged-on-behalf-of: Razvan Nitu 

--

[Issue 18770] Ternary operator returns incorrect value when compiling with -O option

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18770

nebukur...@gmail.com changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 18770] New: Ternary operator returns incorrect value when compiling with -O option

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18770

  Issue ID: 18770
   Summary: Ternary operator returns incorrect value when
compiling with -O option
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: nebukur...@gmail.com

Code:

import std.stdio;

void main() {
foreach (i; 0..2) {
long x = (i % 2 == 0) ? 1 : -1;
x.writeln;
}
}

-
Output (with -O option):
1
4294967295
-
Output (without -O option):
1
-1
-

It seems that -1 is implicitly converted to uint.
As far as I tried, this behavior does not occur when...

# type is int
  int x = (i % 2 == 0) ? 1 : -1 

# negative value is on the left
  long x = (i % 2 == 0) ? -2 : -1  

# condition can be evaluated at compile time(?)
  long x = false ? 1 : -1

All of the above correctly returns negative value with -O option.

--

[Issue 7443] Better diagnostic on wrongly written static constructor

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7443

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/4a023ae3f23480110ab5ac3e0a4915e1b0ad4b6d
Fix Issue 7443 - Better diagnostic on wrongly written static constructor

https://github.com/dlang/dmd/commit/af1d5bd9e10938c605938e2424de78dc941a24b3
Merge pull request #8164 from RazvanN7/Issue_7443

Fix Issue 7443 - Better diagnostic on wrongly written static constructor
merged-on-behalf-of: Razvan Nitu 

--

[Issue 7443] Better diagnostic on wrongly written static constructor

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7443

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18746] function returning empty struct isn't called if used in equality expression

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18746

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18746] function returning empty struct isn't called if used in equality expression

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18746

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/db1f8041670d592c3ad94111a3dc83ba12237932
Fix Issue 18746 - function returning empty struct isn't called if used in
equality expression

https://github.com/dlang/dmd/commit/ebd69c0b9ff4ae64d8e2a4aeef2939c973e6ad5b
Merge pull request #8153 from RazvanN7/Issue_18746

Fix Issue 18746 - function returning empty struct isn't called if used in
equality expression
merged-on-behalf-of: Razvan Nitu 

--

[Issue 18769] New: Cannot infer template parameters for aliased types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18769

  Issue ID: 18769
   Summary: Cannot infer template parameters for aliased types
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Example code:

  struct S(A) {}
  alias T(A) = S!A;

  // OK:
  void withS(A)(S!A x) {}
  withS(S!int());

  // "foo cannot deduce function from argument types":
  void withT(A)(T!A x) {}
  withT(S!int());

Aliases in parameter types should be expanded (symbolically) before inferring.

--

[Issue 5227] X ^^ FP at compile-time

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5227

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 5227] X ^^ FP at compile-time

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5227

--- Comment #17 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6767a32f6988c6794815405e01f07250177d6098
fix Issue 5227 - X ^^ FP at compile-time

https://github.com/dlang/dmd/commit/a4fbc9829da9e4b3e6d73859a42dc6e624e9b790
Merge pull request #8071 from WalterBright/fix5227

fix Issue 5227 - X ^^ FP at compile-time
merged-on-behalf-of: Walter Bright 

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18649

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/4790451e11f3891cf74efa54b9e1b2e29fd4eaa9
fix Issue 18649 - curl on Ubuntu 18.04 depends on libcurl4, ...

... .deb installer depends on libcurl3

- depend on libcurl4 | libcurl3 alternative
- degrading libcurl from dependency to recommends would be welcome,
  but does not work because recommendations are not installed for raw
  .deb packages (--fix-broken only installs dependencies).
  `dpkg -i dmd_2.079.1-0_amd64.deb && apt-get --fix-broken install`
- also add suggested libcurl-dev alternative

https://github.com/dlang/installer/commit/8233177ccc37c4ca5e6a8cfdc39b0a06ece5b2d7
Merge pull request #318 from MartinNowak/test_pkg_install

fix Issue 18649 - curl on Ubuntu 18.04 depends on libcurl4, ...

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18649

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18767

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/2f13c2d416490fdb5e62c0d296e42b76c5c02388
Fix Issue 18767 - __xtoHash memberwise hashing shouldn't just sum the member
hashes

https://github.com/dlang/dmd/commit/f4c0c6579b8bca9af003f7221c9a99f241b7fea8
Merge pull request #8175 from n8sh/issue-18767-xtoHash

Fix Issue 18767 - __xtoHash memberwise hashing shouldn't just sum the member
hashes
merged-on-behalf-of: Walter Bright 

--

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18767

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2043

--- Comment #39 from Artem Borisovskiy  ---
Sorry for off-topic, but this discussion brought back memories of the classic
song by Frank C Mantra:

It's a feature, not a bug,
No one really gives a *cough*,
So if you want it to be fixed,
Go on and fork it, badam badam pap-pa,
How hard can it be, badam badam pap-pa,
Trust me, it's worth it, badam badam pap-pa,
In 10 years you'll se!

--