[Issue 18964] -m32 should mean COFF, default is surprising
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
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
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
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
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
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()
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
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
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
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
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
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)
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)
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
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
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
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
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
https://issues.dlang.org/show_bug.cgi?id=18960 Richard Cattermole changed: What|Removed |Added Keywords||bootcamp --
[Issue 18916] ICE using Typedef and __LINE__
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__
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
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
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.
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
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? --
