[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #9 from Rainer Schuetze r.sagita...@gmx.de 2013-08-28 23:29:36 PDT --- Your're right, a function would be simpler. It might be a little less efficient because of the indirect jump, but avoids the two indirect data accesses through the import table. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10919] New: typeof should accept types
http://d.puremagic.com/issues/show_bug.cgi?id=10919
Summary: typeof should accept types
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@me.com
--- Comment #0 from Jacob Carlborg d...@me.com 2013-08-28 23:52:24 PDT ---
Currently typeof only accepts expressions. I think it would be useful if typeof
accepts types as well and just evaluate to the type given. This will make
metaprogramming simpler.
void foo (alias T) ()
{
alias U = typeof(T);
}
foo!(3); // ok
foo!(Object); // error, Object is not an expression
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10898] LockingTextWriter segfaults in .init state
http://d.puremagic.com/issues/show_bug.cgi?id=10898 --- Comment #2 from github-bugzi...@puremagic.com 2013-08-29 00:02:53 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/ba9c8fc3bfcde5e64eda7d28427b33dece12ad69 fix locking text writer postblit/dtor Both should handle T.init correctly Fix issue 10898 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
http://d.puremagic.com/issues/show_bug.cgi?id=7067 --- Comment #18 from github-bugzi...@puremagic.com 2013-08-29 00:34:46 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/8d9233cf8b9e4d27bd70dd0fcd171d2f6dc2f2c0 Partial fix for Issues 7067 and 10434 - std.random.RandomCover The existing RandomCover design is fatally flawed because it requires a RNG as input, which it then copies internally by value. So, unless the user is smart enough to pass something like e.g. SomeRNG(unpredictableSeed), there will be unintended correlations in random behaviour. This partial fix follows the design of RandomSample in allowing RandomCover to use the thread-global default RNG rndGen. It also improves the choice of template parameter and variable names in line with Issue 10434. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10868] std.string.translate should take an optional buffer
http://d.puremagic.com/issues/show_bug.cgi?id=10868 --- Comment #7 from github-bugzi...@puremagic.com 2013-08-29 00:30:27 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5ec5c213b0b47eeccfa9a335da362a29cb1e0fdf Fixes Issue 10868 - std.string.translate should have an overload that takes an output buffer. https://github.com/D-Programming-Language/phobos/commit/d6b8a21157caec2025ce70bfa259c4c912a969b7 Merge pull request #1501 from AndrejMitrovic/Fix10868 Issue 10868 - std.string.translate should have an overload that takes an output buffer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10434] Don't use Random as template parameter name in std.random (or anywhere else)
http://d.puremagic.com/issues/show_bug.cgi?id=10434 --- Comment #3 from github-bugzi...@puremagic.com 2013-08-29 00:34:59 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/8d9233cf8b9e4d27bd70dd0fcd171d2f6dc2f2c0 Partial fix for Issues 7067 and 10434 - std.random.RandomCover The existing RandomCover design is fatally flawed because it requires a RNG as input, which it then copies internally by value. So, unless the user is smart enough to pass something like e.g. SomeRNG(unpredictableSeed), there will be unintended correlations in random behaviour. This partial fix follows the design of RandomSample in allowing RandomCover to use the thread-global default RNG rndGen. It also improves the choice of template parameter and variable names in line with Issue 10434. https://github.com/D-Programming-Language/phobos/commit/2c9ecb8bd146a77c5ca450a69771b0d9dfcdf732 Partial fix for Issue 10434 - std.random.RandomSample In line with changes to RandomCover, this patch tweaks the choice of template parameter and variable names in order to bring clarity and uniformity to the module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10920] New: template instantiation order dependent link failure problem
http://d.puremagic.com/issues/show_bug.cgi?id=10920
Summary: template instantiation order dependent link failure
problem
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: link-failure
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-08-29 00:52:52 PDT ---
Current dmd has an essential problem around template instantiation.
It is rely on the semantic order, and would cause undefined symbol error in
link phase.
Reduced code:
// foo.d
import bar;
void main() {
BitArray ba;
version(A) ba.toString();
FormatSpec!char fs;
fs.func();
}
// bar.d
struct FormatSpec(C) { void func() {} }
struct BitArray {
auto toString() { FormatSpec!char fs; fs.func(); }
}
Command line:
$ dmd foo.d
-- OK
$ dmd -version=A foo.d
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
Error 42: Symbol Undefined _D3baz8BitArray8toStringMFZv
--- errorlevel 1
-- NG
When -version=A switch is not specified, FormatSpec!char is instantiated on the
function main in foo module at first. It would emit the the instance in the
member of foo module, then codegen phase would output the generated code
correctly.
When -version=A switch is specified, the ba.toString() call runs the semantic3
of the function BitArray.toString first. It would instantiate FormatSpec!char
in bar module, then emit the instance in the member of bar module.
This is a serious issue. If modules are separately compiled, and templates are
already instantiated in the imported module, it could cause the undefined
symbol errors.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10920] template instantiation order dependent link failure problem
http://d.puremagic.com/issues/show_bug.cgi?id=10920 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-08-29 01:03:48 PDT --- I think this is one of the cause of bug 10631. And, unfortunately, long term bug fix around template opEquals/opAssign/opCmp - e,g, fixing bug 3789, bug 4424, bug 3659, and others - had increased the criticalness of this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10767] Regression (2.057): Type inference does not work with a function with a UDT parameter
http://d.puremagic.com/issues/show_bug.cgi?id=10767 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #4 from yebblies yebbl...@gmail.com 2013-08-29 20:45:45 EST --- (In reply to comment #1) Btw, I keep forgetting whether the version in the regression title should refer to the last working version, or the first version introducing the bug? The first version introducing the bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10787] static ~this attributes position
http://d.puremagic.com/issues/show_bug.cgi?id=10787 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10787] static ~this attributes position
http://d.puremagic.com/issues/show_bug.cgi?id=10787 sibaqexozequg...@tempomail.fr changed: What|Removed |Added CC||sibaqexozequgaba@tempomail. ||fr --- Comment #3 from sibaqexozequg...@tempomail.fr 2013-08-29 05:34:45 PDT --- I'm not sure it's fixed. See comments here: https://github.com/D-Programming-Language/dmd/pull/2460 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10787] static ~this attributes position
http://d.puremagic.com/issues/show_bug.cgi?id=10787 --- Comment #4 from yebblies yebbl...@gmail.com 2013-08-29 22:39:54 EST --- The presented test case passes, so it is fixed. If there are other known cases please post them and reopen or (preferred) open a new bug report for them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10795] Bad return type of ParameterIdentifierTuple if there is no arguments
http://d.puremagic.com/issues/show_bug.cgi?id=10795
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #1 from yebblies yebbl...@gmail.com 2013-08-29 22:37:38 EST ---
What would you expect it to be?
It expands to:
import std.stdio;
import std.traits;
void foo() {
}
void main() {
enum arr = [ ];
writeln(typeof(arr).stringof);
}
And arr is correctly inferred to have a type of void[] (the type of the literal
[]). There are no expressions the the result of ParameterIdentifierTuple to
infer any other type from.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10801] std.regex: support for lookbehind in ctRegex
http://d.puremagic.com/issues/show_bug.cgi?id=10801 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2013-08-29 22:46:02 EST --- Andrei, it would be helpful if you could please comment on why these seemingly normal bugs are blockers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10840] [CTFE] *this._data.arr is not yet implemented at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10840 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10921] scoped returns a reference to an uninitialized object
http://d.puremagic.com/issues/show_bug.cgi?id=10921
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-29
07:01:00 PDT ---
Note however that it only fails when declaring, not when assigning. The
following works properly:
-
import std.conv;
import std.typecons;
class Point
{
this(int x, int y)
{
this.x = x;
this.y = y;
}
int x;
int y;
}
void main()
{
auto p1 = scoped!Point(1, 2);
assert(p1.x == 1, p1.x.text); // ok
assert(p1.y == 2, p1.y.text); // ok
Point p2 = p1;
assert(p2.x == 1, p2.x.text); // ok
assert(p2.y == 2, p2.y.text); // ok
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10921] scoped returns a reference to an uninitialized object
http://d.puremagic.com/issues/show_bug.cgi?id=10921 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-29 07:04:28 PDT --- (In reply to comment #0) - Point p2 = scoped!Point(1, 2); assert(p2.x == 1, p2.x.text); // fails, == 0 assert(p2.y == 2, p2.y.text); // fails, == 0 } - I see now what's going on, the internal voldemort type `static struct Scoped` has a dtor, and it is called because this struct is thrown away when you just want to assign the reference to the object at the call site. So the bug report itself is invalid, however this should really be documented because it's very hard to spot what went wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #10 from Martin Nowak c...@dawg.eu 2013-08-29 07:49:41 PDT --- (In reply to comment #7) A few random comments: - I think in a situation where you want to use the same code for static and dynamic linking, export is not usable. I'd propose to export every public symbol at module granularity depending on a compile switch. I'm not a big of conflating protection and export. For example you could split a library in two DLLs in which case you might need to export/import private and package protected symbols. - but then, there is no easy way to tell whether symbols in a module are imported from a static or dynamic library. This distinction is necessary though, as the code is different for both situations. Can you tell a bit more about this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8795] mixing in switch or interface; makes dmd segfault
http://d.puremagic.com/issues/show_bug.cgi?id=8795 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #2 from hst...@quickfur.ath.cx 2013-08-29 08:02:05 PDT --- https://github.com/D-Programming-Language/dmd/pull/2504 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10787] static ~this attributes position
http://d.puremagic.com/issues/show_bug.cgi?id=10787 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Henning Pohl henn...@still-hidden.de 2013-08-29 08:10:44 PDT --- This is not fixed completely, Andrei pulled a bit too fast. Take a look at my comment: https://github.com/D-Programming-Language/dmd/pull/2460 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #11 from Benjamin Thaut c...@benjamin-thaut.de 2013-08-29 08:28:06 PDT --- When a variable is accessed which is linked in through a static library the compiler generates a direct access. If it is linked in through a dynamic library however the compiler needs to generate another level of indirection through the import table. Which is done by referencing _imp_ symbol instead of the original symbol directly. Thats wyh the compiler has to know if the symbol is imported from a dynamic or static library. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10801] std.regex: support for lookbehind in ctRegex
http://d.puremagic.com/issues/show_bug.cgi?id=10801 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-29 08:39:02 PDT --- Fixed by: https://github.com/D-Programming-Language/phobos/commit/c37a5d865a636137d037b2df3d172f4058798df3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10913] [2.064 git-head] regex/demange compilation failure
http://d.puremagic.com/issues/show_bug.cgi?id=10913 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #4 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-29 08:53:03 PDT --- https://github.com/D-Programming-Language/phobos/pull/1532 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #12 from Benjamin Thaut c...@benjamin-thaut.de 2013-08-29 09:50:15 PDT --- I found a excelent blog post on this topic, especially the auto-linking part of it is interresting: http://blog.omega-prime.co.uk/?p=115 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10322] std.random.RandomSample.index() returns wrong value if called before front()
http://d.puremagic.com/issues/show_bug.cgi?id=10322 --- Comment #5 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-08-29 10:24:37 PDT --- Fix submitted: https://github.com/D-Programming-Language/phobos/pull/1533 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10571] formattedWrite error with delegate and string
http://d.puremagic.com/issues/show_bug.cgi?id=10571
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #3 from monarchdo...@gmail.com 2013-08-29 10:27:33 PDT ---
(In reply to comment #0)
I can't format a string into a delegate taking a 'const char[]'. This seems
wrong to me.
--
import std.format;
void main()
{
string buf;
formattedWrite((in char[] s) { buf ~= s; }, %s, hello);
assert(buf == hello);
}
--
Yup. The branches char/string don't work with a delegate sink that accepts a
const(char)[]. Here is a somewhat reduced case.
//
import std.format;
void main()
{
FormatSpec!char f;
formatValue((const(char)[]){}, '本', f);
formatValue((const(char)[]){}, a, f);
}
//
The root issue is that formatValue for wide characters doesn't actually work.
It just calls put and hopes put will magically do the work :D
formatValue for strings then also fails, because it has to compile the %r
path (raw), which iterates over the string as a range (dchars), and then prints
these raw with formatValue(dchar), which, again, doesn't work.
The reason we haven't seen this failure in the testers yet, is that std.format
is mostly unittest using Appender, and Appender *knows* how to transcode,
making it a very poor choice for thorough testing.
In any case, this gets fixed by my put fix:
https://github.com/D-Programming-Language/phobos/pull/1439
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #13 from Rainer Schuetze r.sagita...@gmx.de 2013-08-29 11:07:40 PDT --- Nice blog post. I have implemented something similar to auto-import by adding some additional relocation data for data accesses. At program start the addresses that are relocated to the import table are patched. Unfortunately this does not work for 64-bit applications, because relocations inside a dmd generated binary are 32-bit pc-relative only. You cannot put the address to a variable insde another DLL there as it might be anywhere in the 64-bit address space and out of reach for the 32-bit relative address. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #14 from Rainer Schuetze r.sagita...@gmx.de 2013-08-29 11:12:17 PDT --- (In reply to comment #10) I'm not a big of conflating protection and export. For example you could split a library in two DLLs in which case you might need to export/import private and package protected symbols. I guess you are referring to public symbols only. Actually anything is fine for me, but I guess it doesn't really make sense for private symbols as you are not allowed to access them from another module anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #15 from Martin Nowak c...@dawg.eu 2013-08-29 11:38:04 PDT --- (In reply to comment #11) When a variable is accessed which is linked in through a static library the compiler generates a direct access. If it is linked in through a dynamic library however the compiler needs to generate another level of indirection through the import table. Which is done by referencing _imp_ symbol instead of the original symbol directly. Thats wyh the compiler has to know if the symbol is imported from a dynamic or static library. Maybe my understanding of the Windows mechanism is wrong, but I don't think that the exported symbol has to be different. All the runtime binding happens in the import library and which is similar to the PLT for ELF. Code that refers to an imported symbol will then statically link against the import library. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #16 from Benjamin Thaut c...@benjamin-thaut.de 2013-08-29 11:44:50 PDT --- Maybe my understanding of the Windows mechanism is wrong, but I don't think that the exported symbol has to be different. All the runtime binding happens in the import library and which is similar to the PLT for ELF. Code that refers to an imported symbol will then statically link against the import library. Yes for functions symbols this is true, but data symbols require special handling as described before. What are you trying to suggest with this statement? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10136] Segfault on File struct, map and array
http://d.puremagic.com/issues/show_bug.cgi?id=10136 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #17 from Martin Nowak c...@dawg.eu 2013-08-29 11:54:03 PDT --- (In reply to comment #16) Yes for functions symbols this is true, but data symbols require special handling as described before. What are you trying to suggest with this statement? Well, the question is, whether we can annotate symbols with export and still create static libraries. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #18 from Benjamin Thaut c...@benjamin-thaut.de 2013-08-29 11:58:13 PDT --- Nice blog post. I have implemented something similar to auto-import by adding some additional relocation data for data accesses. At program start the addresses that are relocated to the import table are patched. Unfortunately this does not work for 64-bit applications, because relocations inside a dmd generated binary are 32-bit pc-relative only. You cannot put the address to a variable insde another DLL there as it might be anywhere in the 64-bit address space and out of reach for the 32-bit relative address. A optimization like this would be nice, but walter already stated that he preferes the classical way (another level of indirection). Maybe we should first concentrate on the other issues at hand before discussing optimizations. The most important beeing: - when does export mean dllimport and when dllexport. Newsgroup discussion brought up that we could enable dllimport/dllexport per module (including all submodules) via a command line switch. - do we want a export all public symbols feature (discussion on the newsgroup brought up that c++ is trying to move away from this, maybe we should too) - Should exporting of entire classes / structs be possible? E.g. marking a class es export, exports its vtable, typeinfo, all protected / public functions, static members, etc. - Which informations about modules need to be exported? Will they be automatically exported as soon as the module has a single exported function / class / variable? Well, the question is, whether we can annotate symbols with export and still create static libraries. At the moment: no. But we should create a solution where this very case will work. Proposed solution. 'export' is always a no-op unless you specifiy otherwise using a command line switch to the compiler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10922] New: Compiler segfaults when using __traits(parent, {})
http://d.puremagic.com/issues/show_bug.cgi?id=10922
Summary: Compiler segfaults when using __traits(parent, {})
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monkeywork...@hotmail.com
--- Comment #0 from monkeywork...@hotmail.com 2013-08-29 12:01:51 PDT ---
uint fib = (in uint n) pure nothrow {
enum self = __traits(parent, {});
return (n 2) ? n : self(n - 1) + self(n - 2);
};
void main()
{
import std.stdio;
writeln(fib(39));
}
This code causes a segfault, as does giving fib the auto storage class instead
of uint. If the code is changed to:
uint fib (in uint n) pure nothrow {
immutable self = __traits(parent, {});
return (n 2) ? n : self(n - 1) + self(n - 2);
};
Then it does not segfault.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10918] ICE(arrayop.c:526) involving array ops on real[]
http://d.puremagic.com/issues/show_bug.cgi?id=10918 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Keywords||pull CC||henn...@still-hidden.de --- Comment #3 from Henning Pohl henn...@still-hidden.de 2013-08-29 12:21:52 PDT --- https://github.com/D-Programming-Language/dmd/pull/2505 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10918] ICE(arrayop.c:526) involving array ops on real[]
http://d.puremagic.com/issues/show_bug.cgi?id=10918 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Henning Pohl henn...@still-hidden.de 2013-08-29 12:43:51 PDT --- *** This issue has been marked as a duplicate of issue 10626 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10626] ICE with vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=10626 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #5 from Henning Pohl henn...@still-hidden.de 2013-08-29 12:43:51 PDT --- *** Issue 10918 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10918] ICE(arrayop.c:526) involving array ops on real[]
http://d.puremagic.com/issues/show_bug.cgi?id=10918 --- Comment #5 from hst...@quickfur.ath.cx 2013-08-29 13:15:57 PDT --- Confirmed fixed in git HEAD (46e495b), thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9640] Add #line overload to restore natural line numbering / module name
http://d.puremagic.com/issues/show_bug.cgi?id=9640 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Keywords||pull CC||henn...@still-hidden.de --- Comment #1 from Henning Pohl henn...@still-hidden.de 2013-08-29 14:37:48 PDT --- https://github.com/D-Programming-Language/dmd/pull/2506 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #19 from Martin Nowak c...@dawg.eu 2013-08-29 15:05:57 PDT ---
(In reply to comment #18)
- when does export mean dllimport and when dllexport. Newsgroup discussion
brought up that we could enable dllimport/dllexport per module (including all
submodules) via a command line switch.
There are some problems with the current implementation.
export void foo() {} // definition = dllexport
export void foo(); // declaration = dllimport
export int a = 0;// definition = dllexport
export int a;// declaration = dllimport // fails because it's actually
a definition
export extern int a; // declaration = dllimport
It would be great if we could avoid extra .di headers.
- do we want a export all public symbols feature (discussion on the newsgroup
brought up that c++ is trying to move away from this, maybe we should too)
Please let's try to go into the other direction on Unix too.
You can find more about the reasoning here.
http://gcc.gnu.org/wiki/Visibility
http://people.redhat.com/drepper/dsohowto.pdf
- Should exporting of entire classes / structs be possible? E.g. marking a
class es export, exports its vtable, typeinfo, all protected / public
functions,
static members, etc.
Yes, because there is no way to annotate compiler generated data.
Once again please stay away from abusing protection for export because it
creates too many problems for future language extensions, e.g. maintaining
private symbols for ABI compatibility, module definitions in multiple
files/objects, partial classes. Linking and symbol protection are fundamentally
different concepts and we should offer orthogonal control.
- Which informations about modules need to be exported? Will they be
automatically exported as soon as the module has a single exported function /
class / variable?
Yes, it's hidden compiler data and you might need to link against the
ModuleInfo and some other symbols.
Well, the question is, whether we can annotate symbols with export and
still
create static libraries.
At the moment: no. But we should create a solution where this very case will
work. Proposed solution. 'export' is always a no-op unless you specifiy
otherwise using a command line switch to the compiler.
That sounds like a reasonable solution when we can't do better.
Also see the alias discussion on the newsgroup
http://forum.dlang.org/post/kvo9gm$8fs$1...@digitalmars.com.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #20 from Martin Nowak c...@dawg.eu 2013-08-29 15:37:26 PDT --- (In reply to comment #19) Well, the question is, whether we can annotate symbols with export and still create static libraries. At the moment: no. But we should create a solution where this very case will work. Proposed solution. 'export' is always a no-op unless you specifiy otherwise using a command line switch to the compiler. That sounds like a reasonable solution when we can't do better. Also see the alias discussion on the newsgroup http://forum.dlang.org/post/kvo9gm$8fs$1...@digitalmars.com. That wouldn't work in the case where you create a DLL that both exports symbols and imports symbols from another DLL. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10921] scoped returns a reference to an uninitialized object
http://d.puremagic.com/issues/show_bug.cgi?id=10921 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-08-29 18:38:53 PDT --- (In reply to comment #2) (In reply to comment #0) - Point p2 = scoped!Point(1, 2); assert(p2.x == 1, p2.x.text); // fails, == 0 assert(p2.y == 2, p2.y.text); // fails, == 0 } - I see now what's going on, the internal voldemort type `static struct Scoped` has a dtor, and it is called because this struct is thrown away when you just want to assign the reference to the object at the call site. So the bug report itself is invalid, however this should really be documented because it's very hard to spot what went wrong. We should disable the implicit conversion from Scoped to Point. I think we can use Proxy mixin instead of alias this for the purpose. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9816] Export is mostly broken
http://d.puremagic.com/issues/show_bug.cgi?id=9816 --- Comment #21 from Martin Nowak c...@dawg.eu 2013-08-29 19:29:11 PDT --- To summarize the alias proposal. For every exported function definition we also emit an alias symbol _imp_funcname. For every exported data definition we emit a weakly linked read-only pointer T* _imp_var = var. Whenever an exported symbol is called or accessed this is done using the _imp_* symbol. When such code gets linked with an import library it will correctly work with a DLL. When such code gets linked with a static library it will reference the correct definitions. The simple export attribute is sufficient for all use-cases, no worries about dllimport/dllexport/no-op. If we were able to use whole program optimization the linker could optimize away the additional data access indirection when linking statically. I don't think the last point is too critical because exporting data is rarely done and rather a bad practice. Also this only applies to the API boundary which shouldn't be a performance hotspot. For ELF export should simply make a symbol visible, otherwise symbols should be hidden by default. Any ideas about Mach-O? Same as ELF? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9640] Add #line overload to restore natural line numbering / module name
http://d.puremagic.com/issues/show_bug.cgi?id=9640 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Severity|minor |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10923] New: ICE in backend with postincrement on double in vector op on 64 bit
http://d.puremagic.com/issues/show_bug.cgi?id=10923
Summary: ICE in backend with postincrement on double in vector
op on 64 bit
Product: D
Version: D1 D2
Platform: x86_64
OS/Version: All
Status: NEW
Keywords: ice
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: yebbl...@gmail.com
--- Comment #0 from yebblies yebbl...@gmail.com 2013-08-30 13:53:12 EST ---
This code ICEs when compiled on 64-bit
Most likely related to DMD's xmm codegen.
void main()
{
double[2] v, x;
double z;
double[2] s = v[] * z++;
double[2] t = v[] * z--;
}
Internal error: ../ztc/cg87.c 201
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
