[Issue 13696] Missing entry for unicode code point literals on the lexer page
https://issues.dlang.org/show_bug.cgi?id=13696 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||spec Severity|enhancement |normal --
[Issue 13696] New: Missing entry for unicode code point literals on the lexer page
https://issues.dlang.org/show_bug.cgi?id=13696 Issue ID: 13696 Summary: Missing entry for unicode code point literals on the lexer page Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com An excerpt from Ali's book: - http://ddili.org/ders/d.en/characters.html Specifying the Unicode values of the characters by using the \ufour_digit_value syntax for wchar, and the \Ueight_digit_value syntax for dchar. (Note u vs. U.) The Unicode values must be specified in hexadecimal: wchar Ğ_w = '\u011e'; dchar Ğ_d = '\U011e'; These methods can be used to specify the characters within strings as well. For example, the following two lines have the same string literals: writeln(Résumé preparation: 10.25€); writeln(\x52\eacute;sum\u00e9 preparation: 10.25\euro;); - This info is missing on our lexer page: http://dlang.org/lex.html --
[Issue 9623] Illegal Win64 linker optimization?
https://issues.dlang.org/show_bug.cgi?id=9623 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de --- See also issue 10664. It is the reason why we currently have -L/OPT:NOICF in sc.ini. --
[Issue 12723] Support compiling C/C++ files in D projects
https://issues.dlang.org/show_bug.cgi?id=12723 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de --- I added basic C/C++ support in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.40-beta2 --
[Issue 13697] New: Private method hides public static method
https://issues.dlang.org/show_bug.cgi?id=13697
Issue ID: 13697
Summary: Private method hides public static method
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: an...@s-e-a-p.de
Following code fails with errors:
class test.A member b is not accessible
module app;
import test;
void main()
{
A.b();
}
module test;
class A
{
private void b(){}
static void b(string b){}
}
Comment from Jonathan M Davis (forum):
That looks like a bug. All you have to do is change the order of the two
function declarations or rename the non-static one to something else, and it
compiles. So, somehow, the fact that the non-static one has the same name as
the static one and the fact that it comes first screws up accessing the
static one. And explicitly marking the static one as public doesn't help.
--
[Issue 13686] Reading unicode string with readf (%s) produces a wrong string
https://issues.dlang.org/show_bug.cgi?id=13686 --- Comment #5 from ag0ae...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2663 --
[Issue 12320] std.stdio.LockingTextReader populates .front in .empty
https://issues.dlang.org/show_bug.cgi?id=12320 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from ag0ae...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2663 --
[Issue 13698] New: ICE(e2ir.c) on on simd call
https://issues.dlang.org/show_bug.cgi?id=13698
Issue ID: 13698
Summary: ICE(e2ir.c) on on simd call
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
This code gives Internal error: e2ir.c 3661:
import core.simd;
void main() {
float4 a;
ubyte b = 0;
a = __simd(XMM.SHUFPS, a, b);
}
--
[Issue 13698] ICE(e2ir.c) on on simd call
https://issues.dlang.org/show_bug.cgi?id=13698 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added Keywords||ice, SIMD --
[Issue 13253] use more scoped imports in phobos
https://issues.dlang.org/show_bug.cgi?id=13253 --- Comment #2 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/phobos/pull/2658 --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Dicebot pub...@dicebot.lv changed: What|Removed |Added Keywords||industry Priority|P2 |P1 Status|RESOLVED|REOPENED CC||pub...@dicebot.lv Resolution|WONTFIX |--- Severity|normal |regression --- Comment #3 from Dicebot pub...@dicebot.lv --- Reopining it and marking as critical regression issue. Also with industry keyword. This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process. However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Walter original reasoning about breaking original code is completely unapplicable here as any code that currently compiles with this pattern will segfault at runtime anyway. There can't be any legit working code out there to break. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #4 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Wouldn't ref work? It seems to work for me. -Steve --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Steven Schveighoffer from comment #4) (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Wouldn't ref work? It seems to work for me. Sorry, I quoted the wrong part of your post, it should have been: (In reply to Dicebot from comment #3) This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #6 from bearophile_h...@eml.cc --- (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy. --
[Issue 13165] Spurious Warning: statement is not reachable with -profile, If return statement exists in void main()
https://issues.dlang.org/show_bug.cgi?id=13165 Nick Treleaven ntrel-...@mybtinternet.com changed: What|Removed |Added CC||ntrel-...@mybtinternet.com --- Comment #1 from Nick Treleaven ntrel-...@mybtinternet.com --- I can't reproduce this with dmd 2.066.0. --
[Issue 13165] Spurious Warning: statement is not reachable with -profile, If return statement exists in void main()
https://issues.dlang.org/show_bug.cgi?id=13165 --- Comment #2 from Nick Treleaven ntrel-...@mybtinternet.com --- Sorry, I can reproduce it with -profile. --
[Issue 7232] Warning: statement is not reachable has no line number
https://issues.dlang.org/show_bug.cgi?id=7232
Nick Treleaven ntrel-...@mybtinternet.com changed:
What|Removed |Added
CC||ntrel-...@mybtinternet.com
--- Comment #5 from Nick Treleaven ntrel-...@mybtinternet.com ---
There's a missing line number with -w here also (recent dmd):
import std.stdio;
void f()
{
throw new Exception(msg);
scope(exit) write(5);
scope(success) write(6);
}
--
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #7 from Dicebot pub...@dicebot.lv --- The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it. In general we have looks like C, works like C slogan. My point is that this is especially important with function _explicitly_ marked as should work like C - any mismatch between extern(C) ABI and real C ABI is an important bug. --
[Issue 13699] New: thread creation and starting should be nothrow
https://issues.dlang.org/show_bug.cgi?id=13699 Issue ID: 13699 Summary: thread creation and starting should be nothrow Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu A lot of core.thread functions are not nothrow because they escalate errors of the underlying implementation (pthread, Windows threads) by throwing a ThreadException. Most of those functions should only fail on resource exhaustion and recovering from that is a bit tricky. So I wonder if we should handle them as fatal errors and mark the high-level core.thread functions as nothrow. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #8 from Dicebot pub...@dicebot.lv --- (In reply to bearophile_hugs from comment #6) I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy. There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #9 from bearophile_h...@eml.cc --- (In reply to Dicebot from comment #8) There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed. D fixed-size arrays are values. C language lacks those values, so I think D doesn't have a C ABI to respect. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #10 from Dicebot pub...@dicebot.lv --- C has static arrays. C allows passing static arrays as function arguments. HOW it is passing them is defined by ABI and D rules are irrelevant here. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #11 from Steven Schveighoffer schvei...@yahoo.com --- The issue here is -- we use the non-mangling feature of C calls to override type checking inside druntime. So even if something is extern(C) it can actually be implemented in D. That function may never need to be called or used in C code at all. Why shouldn't D support ref for C? All it is doing is auto-taking the address of the parameter, which maps perfectly to accepting a pointer or array argument. I think the important pieces of the C ABI to implement are where parameters go, and the lack of name mangling. Other than that, how to pass certain types is more fuzzy. As another example, on a 32-bit system, C's long is 32-bit. But D's long is 64 bit. What to do here? extern(C) foo(long x); Clearly, it's not too important the type of x, but how big it actually is. This leads one to simply type it as int instead, and move on. This hasn't really caused tremendous issues or difficulties. I think really the crux of the push for this bug is more that D2 behaves differently vs. D1 than D2 implements the C ABI incorrectly. Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #12 from Dicebot pub...@dicebot.lv --- (In reply to Steven Schveighoffer from comment #11) The issue here is -- we use the non-mangling feature of C calls to override type checking inside druntime. So even if something is extern(C) it can actually be implemented in D. That function may never need to be called or used in C code at all. This is abuse and needs to be fixed. We have pragma(mangle) to override mangling. http://dlang.org/attribute.html#linkage is pretty clear on legitimate use cases this feature was designed for. Why shouldn't D support ref for C? All it is doing is auto-taking the address of the parameter, which maps perfectly to accepting a pointer or array argument. Exactly because it is special case - it takes a language feature that does not have clear mapping to C feature and makes use of ABI details to work it as-is. It is not bad on its own but quite puzzling. As another example, on a 32-bit system, C's long is 32-bit. But D's long is 64 bit. What to do here? extern(C) foo(long x); Ideally this should use C interpretation too but I recognize how it is totally impractical. This is not the case for static array arguments. Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move. You call tweaking own code (that makes use of undefined language area) to address compiler regression a right move? --
[Issue 13253] use more scoped imports in phobos
https://issues.dlang.org/show_bug.cgi?id=13253 Илья Ярошенко ilyayaroshe...@gmail.com changed: What|Removed |Added CC||ilyayaroshe...@gmail.com --- Comment #3 from Илья Ярошенко ilyayaroshe...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2659 --
[Issue 13253] use more scoped imports in phobos
https://issues.dlang.org/show_bug.cgi?id=13253 --- Comment #4 from Илья Ярошенко ilyayaroshe...@gmail.com --- std.range package https://github.com/D-Programming-Language/phobos/pull/2661 --
[Issue 11216] Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4115 --
