[Issue 18964] -m32 should mean COFF, default is surprising

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18964

--- Comment #2 from Manu  ---
That's where he started, but the trouble usually comes when wanting to build
-m32 after building -m64. The errors are surprising, and he spent time trying
to understand what was wrong with his libs, maybe pathing problems, a good
amount of head-scratching, etc... nope, it's just 'broken'!
No reasonable person would expect OMF.

I don't know why, but it's still common to emit both binaries in windows
builds.
There's a sort of de-facto standard that distributing libs should include the
full suite.


> Also, when you submit a PR [...]

Oh okay, can do in future. Honestly, I expected this would have exactly no
traction... but I think it's worth consideration.

It's not any skin off anyone's noses here, but unsuspecting new users only
really stand to be surprised and/or annoyed by the current arrangement.

--


[Issue 18964] -m32 should mean COFF, default is surprising

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18964

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Did you suggest he use -m64?

Also, when you submit a PR for an issue please include it in the issue:

https://github.com/dlang/dmd/pull/8347

or nobody perusing bugzilla will know there's a PR.

--


[Issue 18965] private attribute does not make function private when extern(Windows) attribute is used

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18965

Richard Cattermole  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alphaglosi...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from Richard Cattermole  ---
This is the correct behavior.

extern(C) disables name mangling, extern(Windows) only differs for ABI and
slightly with symbol naming.

Without name mangling occuring they are the same symbol no matter what module
it is in as defined by C compilers.

--


[Issue 18965] New: private attribute does not make function private when extern(Windows) attribute is used

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18965

  Issue ID: 18965
   Summary: private attribute does not make function private when
extern(Windows) attribute is used
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: link-failure
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ben.stembri...@gmail.com

If you have multiple functions with the same name in different modules that
have the attribute extern(Windows) and are marked as private, it will cause a
link error. This also happens with extern(C) linkage

simple example with 2 modules:

module other;
extern(C)
private void test()
{
}

module main;
extern(C)
private void test()
{
}
int main(string[] argv)
{
 test();
 return 0;
}


Error 1: Previous Definition Different : _test

this is with  dmd v2.080.0 windows x86

--


[Issue 18964] -m32 should mean COFF, default is surprising

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18964

Manu  changed:

   What|Removed |Added

Summary|-m32 should mean COFF,  |-m32 should mean COFF,
   |default is not useful   |default is surprising

--


[Issue 18964] New: -m32 should mean COFF, default is not useful

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18964

  Issue ID: 18964
   Summary: -m32 should mean COFF, default is not useful
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

`-m32` should be changed to `-m32omf`, and mscoff should be default. They need
to match and nobody should experience nasty surprises about object format
mismatches when trying to do 32bit builds.

The default (no -m arg given) current emits 32bit OMF. This isn't generally
helpful.
Personally, I think it's also time that DMD chose -m64 by default when no
argument is given; it's 2018, it's been over a decade since it was possible to
buy a 32bit x86.

I had to pacify a frustrated colleague who wasted their time trying to work out
why the x86 build wouldn't link, and explain the back-story. They were not at
all satisfied with my explanation >_<

--


[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18026

ag0aep6g  changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com

--- Comment #10 from ag0aep6g  ---
(In reply to JR from comment #9)
> > git clone https://github.com/zorael/kameloso -b 2080-overflow1

Reduced further to a single file (but still with Phobos dependencies):


enum Type
{
x000,x001,x002,x003,x004,x005,x006,x007,x008,x009,
x010,x011,x012,x013,x014,x015,x016,x017,x018,x019,
x020,x021,x022,x023,x024,x025,x026,x027,x028,x029,
x030,x031,x032,x033,x034,x035,x036,x037,x038,x039,
x040,x041,x042,x043,x044,x045,x046,x047,x048,x049,
x050,x051,x052,x053,x054,x055,x056,x057,x058,x059,
x060,x061,x062,x063,x064,x065,x066,x067,x068,x069,
x070,x071,x072,x073,x074,x075,x076,x077,x078,x079,
x080,x081,x082,x083,x084,x085,x086,x087,x088,x089,
x090,x091,x092,x093,x094,x095,x096,x097,x098,x099,
x100,x101,x102,x103,x104,x105,x106,x107,x108,x109,
x110,x111,x112,x113,x114,x115,x116,x117,x118,x119,
x120,x121,x122,x123,x124,x125,x126,x127,x128,x129,
x130,x131,x132,x133,x134,x135,x136,x137,x138,x139,
x140,x141,x142,x143,x144,x145,x146,x147,x148,x149,
x150,x151,x152,x153,x154,x155,x156,x157,x158,x159,
x160,x161,x162,x163,x164,x165,x166,x167,x168,x169,
x170,x171,x172,x173,x174,x175,x176,x177,x178,x179,
x180,x181,x182,x183,x184,x185,x186,x187,x188,x189,
x190,x191,x192,x193,x194,x195,x196,x197,x198,x199,
x200,x201,x202,x203,x204,x205,x206,x207,x208,x209,
x210,x211,x212,x213,x214,x215,x216,x217,x218,x219,
x220,x221,x222,x223,x224,x225,x226,x227,x228,x229,
x230,x231,x232,x233,x234,x235,x236,x237,x238,x239,
x240,x241,x242,x243,x244,x245,x246,x247,x248,x249,
x250,x251,x252,x253,x254,x255,x256,x257,x258,x259,
x260,x261,x262,x263,x264,x265,x266,x267,x268,x269,
x270,x271,x272,x273,x274,x275,x276,x277,x278,x279,
x280,x281,x282,x283,x284,x285,x286,x287,x288,x289,
x290,x291,x292,x293,x294,x295,x296,x297,x298,x299,
x300,x301,x302,x303,x304,x305,x306,x307,x308,x309,
x310,x311,x312,x313,x314,x315,x316,x317,x318,x319,
x320,x321,x322,x323,x324,x325,x326,x327,x328,x329,
x330,x331,x332,x333,x334,x335,x336,x337,x338,x339,
x340,x341,x342,x343,x344,x345,x346,x347,x348,x349,
x350,x351,x352,x353,x354,x355,x356,x357,x358,x359,
x360,x361,x362,x363,x364,x365,x366,x367,x368,x369,
x370,x371,x372,x373,x374,x375,x376,x377,x378,x379,
x380,x381,x382,x383,x384,x385,x386,x387,x388,x389,
x390,x391,x392,x393,x394,x395,x396,x397,x398,x399,
x400,x401,x402,x403,x404,x405,x406,x407,x408,x409,
x410,x411,x412,x413,x414,x415,x416,x417,x418,x419,
x420,x421,x422,x423,x424,x425,x426,x427,x428,x429,
x430,x431,x432,x433,x434,x435,x436,x437,x438,x439,
x440,x441,x442,x443,x444,x445,x446,x447,x448,x449,
x450,x451,x452,x453,x454,x455,x456,x457,x458,x459,
x460,x461,x462,x463,x464,x465,x466,x467,x468,x469,
x470,x471,x472,x473,x474,x475,x476,x477,x478,x479,
x480,x481,x482,x483,x484,x485,x486,x487,x488,x489,
x490,x491,x492,x493,x494,x495,x496,x497,x498,x499,
x500,x501,x502,x503,x504,x505,x506,x507,x508,x509,
x510,x511,x512,x513,x514,x515,x516,x517,x518,x519,
x520,x521,x522,x523,x524,x525,x526,x527,x528,x529,
x530,x531,x532,x533,x534,x535,x536,x537,x538,x539,
x540,x541,x542,x543,x544,x545,x546,x547,x548,x549,
x550,x551,
}

import std.concurrency: send;
import std.format: format;

struct PeekPlugins {}

struct IRCEvent
{
Type type;
byte sender;
string channel;
string content;
string aux;
uint num;
long time;
}

@Type
void onSetCommand()
{
alias s = send!(PeekPlugins, shared IRCPlugin, IRCEvent);
}

interface IRCPlugin {}
class AdminPlugin : IRCPlugin {}

class WHOISRequestImpl
{
void foo()
{
IRCEvent event;
"[%s] @ %s".format(event);
}
}


Fails a bit less reliably, but still 7 out of 10 times.

--


[Issue 18963] Relax restrictions on 'return' parameters when parameter is not a pointer

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18963

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8346

--


[Issue 18958] extern(C++) wchar, dchar mangling not correct

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18958

--- Comment #1 from Manu  ---
wchar_t needs a typedef. It's just an alias, and can't identify it to mangle
properly.
wchar and dchar should be char16_t, char32_t.
DMD doesn't have any C++11 support... so the unit-tests for DMD need
special-case handling.

--


[Issue 18963] New: Relax restrictions on 'return' parameters when parameter is not a pointer

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18963

  Issue ID: 18963
   Summary: Relax restrictions on 'return' parameters when
parameter is not a pointer
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Consider:

  T Identity(T)(return T t) { return t; }

  void bar(int i, void* p) {
Identity(p); // no error
Identity(i); // Error: parameter t is return but function
 // does not return any indirections
  }

The error unreasonably impairs the creation of generic code, and so 'return'
should simply be ignored for such cases.

--


[Issue 18962] readln() removes all '\r' characters from stdin

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18962

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |WONTFIX

--- Comment #1 from Steven Schveighoffer  ---
This is due to libc on windows attempting to fix the line endings for you.
There's not much D can do about it, since it relies on FILE * to do its i/o.

Note that the reason the single readln affects things is likely because
line-endings are altered when the buffer is filled (which is done with one
large read). All future reads can't recover the removed CRs.

If you want the given behavior, set the mode to binary before doing anything:

_setmode(stdin.fileno, _O_BINARY);

The reason it doesn't occur on Linux is because Linux doesn't do anything in
binary mode.

--


[Issue 18962] New: readln() removes all '\r' characters from stdin

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18962

  Issue ID: 18962
   Summary: readln() removes all '\r' characters from stdin
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: laurent.treguier.s...@gmail.com

import std.conv;
import std.stdio;

void main()
{
auto line = readln();
while (!stdin.eof)
{
auto res = stdin.rawRead(new char[1]);

if (res.length)
{
stdout.writeln(res[0].to!int);
}
}
}

This code will remove any '\r' character coming from stdin. Using any file with
CRLF line endings as input, the LF part will be outputed (as its ascii code
10), but not the CR part.
Commenting the `auto line = readln();` line makes `stdin.rawRead()` read '\r'
characters properly; the CR part will be outputed (as its ascii code 13).
This doesn't seem to occur on Linux.

DMD and Phobos version : 2.080.1

--


[Issue 18961] Need give to compiler/linker' warning/errors some codes (like VC)

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18961

--- Comment #1 from OlegZ  ---
you can change the error text to something more digestible over time, but the
error code will remain the same, and you can still find old messages about the
error and new ones

--


[Issue 18961] New: Need give to compiler/linker' warning/errors some codes (like VC)

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18961

  Issue ID: 18961
   Summary: Need give to compiler/linker' warning/errors some
codes (like VC)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: blac...@bk.ru

ref to "what I mean/want"
https://msdn.microsoft.com/en-us/library/zz3ext39.aspx

when I compile my code I got:
> Error: `evt += hz` is not a scalar, it is a `main.Event!(int, string)`
I should remove some text from this error to google it
> to google: Error: is not a scalar, it is a
(after all I still don't understand what wrong with my opOpAssign but)
BETTER to give for warnings/errors codes like DE0005 or DW0220 and prints it
like
> Error DE0005: `evt += hz` is not a scalar, it is a `main.Event!(int, string)`

D-prefix is good for Dlang: DE* for errors, DW* for warnings, DL* for linker
for example

than I will google it like "dlang DE0005" without cuts unnecessary text and I
think that I will find more accurate results with more clear explanations

--


[Issue 18956] latest experimental build crashing a lot

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18956

--- Comment #3 from Rainer Schuetze  ---
I've hit this too: it's a stack overflow that happens because indirections are
now followed more often when printing a value. That's bad when there are
circular references...

Next build should have that fixed.

--


[Issue 14632] Diagnostic improvement for invalid cast with alias this

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14632

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #1 from Nick Treleaven  ---
Reduced:

struct Tuple(T...)
{
alias Types = T;
Types expand;
alias expand this;
}

void test()
{
Tuple!(int, int) point;
auto newPoint = cast(Object)(point);
}

Error messages no longer use '__tup$n$' but could still be improved as per
comment 0:

onlineapp.d(10): Error: cannot cast expression point.__expand_field_0 of type
int to object.Object
onlineapp.d(10): Error: cannot cast expression point.__expand_field_1 of type
int to object.Object

--


[Issue 18899] destroy is inefficient for small structs

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18899

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #10 from Nick Treleaven  ---
For the record, Andrei wants to solve this by not blitting init for primitive
types:
https://github.com/dlang/druntime/pull/2126

> memcpy should be an intrinsic

Would that allow unrolling loops when the length is known at compile-time?

An interim improvement might be to have an array version of std.algorithm.copy
in druntime (which phobos then uses internally).

--


[Issue 18960] New: Function parameter requires name with default value

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18960

  Issue ID: 18960
   Summary: Function parameter requires name with default value
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alphaglosi...@gmail.com

As per spec this should not be possible.

void main() {
Foo foo = 
foo();
}

alias Foo = void function(int=6);

void bar(int v = 6) {
import std.stdio;
writefln("%i", v);   
}

A simple error check can be added here:
https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L2860

--


[Issue 18960] Function parameter requires name with default value

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18960

Richard Cattermole  changed:

   What|Removed |Added

   Keywords||bootcamp

--


[Issue 18916] ICE using Typedef and __LINE__

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18916

--- Comment #3 from Mike Franklin  ---
Same issue, but for __FILE__

--- module1.d
module module1;

struct File
{
string file;
alias file this;

this(string line)
{
this.file = file;
}
}

void foo(File file1 = __FILE__, string file2 = __FILE__)
{
assert(file1 == "module1.d");
assert(file2 == "main.d");
}

--- main.d
import module1;

void main()
{
foo();
}

--


[Issue 18916] ICE using Typedef and __LINE__

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18916

--- Comment #2 from Mike Franklin  ---
Alternate test case that doesn't require Phobos.

struct Line
{
int line;
alias line this;

this(int line)
{
this.line = line;
}
}

void foo(Line line1 = __LINE__, int line2 = __LINE__, int line3 =
int(__LINE__))
{
assert(line1 == 12);
assert(line2 == 21);
assert(line3 == 12);
}

void main()
{
foo();
}

--


[Issue 18956] latest experimental build crashing a lot

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18956

--- Comment #2 from Manu  ---
I didn't compare... I'll check next time I'm doing work.

--


[Issue 15360] typeof is not a template argument

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15360

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--


[Issue 15361] Incomprehensible error message: function declaration without return type.

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15361

RazvanN  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--


[Issue 18956] latest experimental build crashing a lot

2018-06-09 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18956

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
This is with build 1.0.186 from
https://ci.appveyor.com/project/rainers/visuald/history? Is it ok with 1.0.185?

--