[Issue 8260] New: * used three or more times on an array inside std.format.formattedRead
http://d.puremagic.com/issues/show_bug.cgi?id=8260
Summary: * used three or more times on an array inside
std.format.formattedRead
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-06-18 05:12:17 PDT ---
import std.format;
void main() {
int[3] row;
auto text = 10 20 30;
formattedRead(text, %(%d %), row);
}
DMD 2.060alpha:
...\dmd2\src\phobos\std\format.d(555): Error: using * on an array is
deprecated; use *(_param_2).ptr instead
...\dmd2\src\phobos\std\format.d(566): Error: using * on an array is
deprecated; use *(_param_2).ptr instead
test.d(5): Error: template instance
std.format.formattedRead!(string,char,uint[3u]) error instantiating
Part inside formattedRead, that uses * three times:
alias typeof(*args[0]) A;
static if (isTuple!A)
{
foreach (i, T; A.Types)
{
(*args[0])[i] = unformatValue!(T)(r, spec);
skipUnstoredFields();
}
}
else
{
*args[0] = unformatValue!(A)(r, spec);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8260] * used three or more times on an array inside std.format.formattedRead
http://d.puremagic.com/issues/show_bug.cgi?id=8260
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-06-18 05:47:29 PDT ---
The bug is in your code.
void main() {
int[3] row;
auto text = 10 20 30;
//formattedRead(text, %(%d %), row); // bad
formattedRead(text, %(%d %), row); // OK
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8260] * used three or more times on an array inside std.format.formattedRead and not guarded by template constraint
http://d.puremagic.com/issues/show_bug.cgi?id=8260 timon.g...@gmx.ch changed: What|Removed |Added Status|RESOLVED|REOPENED CC||timon.g...@gmx.ch Resolution|INVALID | Summary|* used three or more times |* used three or more times |on an array inside |on an array inside |std.format.formattedRead|std.format.formattedRead ||and not guarded by template ||constraint --- Comment #2 from timon.g...@gmx.ch 2012-06-18 06:11:30 PDT --- Phobos should catch the error with a template constraint instead of showing confusing errors in the template body. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7965] Invalid outer function scope pointer in some cases
http://d.puremagic.com/issues/show_bug.cgi?id=7965 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-06-18 06:45:33 PDT --- https://github.com/D-Programming-Language/dmd/pull/1014 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] New: std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261
Summary: std.traits.ParameterTypeTuple may break existing codes
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-06-18 08:26:10 PDT ---
In 2.060head, is(FuncType PT == function) - PT contains parameter identifiers.
This change is introduced the commit:
https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa
It is useful for more metaprogramming, but this change may break existing codes
that using std.traits.ParameterTypeTuple. See below sample code:
void foo(int num, string name, int[int] map){}
pragma(msg, ParameterTypeTuple!foo);
// In 2.059, prints (int, string, int[int])
// In 2.060head, prints (int num, string name, int[int] map)
void bar(ParameterTypeTuple!foo num) {}
// Error: function test.bar parameter bar.num is already defined
If we change the implementation of ParameterTypeTuple template like follows:
template ParameterTypeTuple(func...)
if (func.length == 1 isCallable!func)
{
static if (is(FunctionTypeOf!(func) P == function))
{
//alias P ParameterTypeTuple;
// Remove parameter names that original function has.
template Id(T) { alias T Id; }
alias staticMap!(Id, P) ParameterTypeTuple;
}
else
static assert(0, argument has no parameters);
}
We can get 'a tuple that contains only parameter types', but it also removes
parameter storage class... breaking existing codes REVISITED!
void foo(ref int x){}
pragma(msg, ParameterTypeTuple!foo); // will prints (int), not (ref int)
In current dmd, all of function parameters have names, written by user, or
named by compiler internally (e.g. _param_0). Then we never get a tuple of
'parameter type with storage class but unnamed'.
Then, if we want to parameter type tuple with storage classes, we cannot remove
parameter name informations from the tuple.
As far as I know, there is no workaround. So I think we should revert the
commit 65acb8ca.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8252] no UFCS for 0 literal
http://d.puremagic.com/issues/show_bug.cgi?id=8252 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-18 10:49:37 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f34f6f0e5d998b3c6977531d7a5ec51c29361274 fix Issue 8252 - no UFCS for 0 literal https://github.com/D-Programming-Language/dmd/commit/4e053160ef351c249fa250a0e2f5a071419ca8f0 Merge pull request #1013 from 9rnsr/fix8252 Issue 8252 - no UFCS for 0 literal -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8262] New: [ICE] sequence alias this
http://d.puremagic.com/issues/show_bug.cgi?id=8262
Summary: [ICE] sequence alias this
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-18 12:30:13 PDT ---
template Seq(T...) { alias T Seq; }
struct S{
int s;
alias Seq!s _;
alias _ this;
}
import std.stdio;
void main(){ writeln(S.init); }
Crashes DMD 2.059 with:
dmd: mtype.c:1279: Type* Type::aliasthisOf(): Assertion `d-type' failed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8252] no UFCS for 0 literal
http://d.puremagic.com/issues/show_bug.cgi?id=8252 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261
Manu turkey...@gmail.com changed:
What|Removed |Added
CC||turkey...@gmail.com
--- Comment #1 from Manu turkey...@gmail.com 2012-06-18 13:31:45 PDT ---
(In reply to comment #0)
In 2.060head, is(FuncType PT == function) - PT contains parameter
identifiers.
This change is introduced the commit:
https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa
It is useful for more metaprogramming, but this change may break existing
codes
that using std.traits.ParameterTypeTuple. See below sample code:
void foo(int num, string name, int[int] map){}
pragma(msg, ParameterTypeTuple!foo);
// In 2.059, prints (int, string, int[int])
// In 2.060head, prints (int num, string name, int[int] map)
void bar(ParameterTypeTuple!foo num) {}
// Error: function test.bar parameter bar.num is already defined
If we change the implementation of ParameterTypeTuple template like follows:
template ParameterTypeTuple(func...)
if (func.length == 1 isCallable!func)
{
static if (is(FunctionTypeOf!(func) P == function))
{
//alias P ParameterTypeTuple;
// Remove parameter names that original function has.
template Id(T) { alias T Id; }
alias staticMap!(Id, P) ParameterTypeTuple;
}
else
static assert(0, argument has no parameters);
}
We can get 'a tuple that contains only parameter types', but it also removes
parameter storage class... breaking existing codes REVISITED!
void foo(ref int x){}
pragma(msg, ParameterTypeTuple!foo); // will prints (int), not (ref int)
In current dmd, all of function parameters have names, written by user, or
named by compiler internally (e.g. _param_0). Then we never get a tuple of
'parameter type with storage class but unnamed'.
Then, if we want to parameter type tuple with storage classes, we cannot
remove
parameter name informations from the tuple.
As far as I know, there is no workaround. So I think we should revert the
commit 65acb8ca.
Can the new behaviour be expressed with a new ParameterTuple! trait or
something?
ParameterTypeTuple! makes sense as just types, but it would be nice to see a
suite: ParameterTyple! with all details, ParameterNameTuple! just names,
ParameterDefaultArgTuple!, you get the idea... ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-06-18 17:16:17 PDT --- You're right, it does break existing code. I thought it was a worthwhile tradeoff to get the functionality Manu needed. But perhaps Manu's idea to do this tuple with a __traits is a better idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-18 17:33:11 PDT --- (In reply to comment #2) You're right, it does break existing code. I thought it was a worthwhile tradeoff to get the functionality Manu needed. But perhaps Manu's idea to do this tuple with a __traits is a better idea. See also the notes in github. https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa#commitcomment-1473583 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8258] Delegates do not respect default parameters
http://d.puremagic.com/issues/show_bug.cgi?id=8258 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-18 18:55:22 PDT --- I think this *regression* is introduced by fixing bug 3866. Now all indirect calls do not consider default arguments even if it is written in type signature. I didn't join the discussion, but it seems to me that current *fix* is too conservative way - it rejects some useful cases like this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8263] New: wrong offset in IMAGE_DEBUG_DIRECTORY
http://d.puremagic.com/issues/show_bug.cgi?id=8263 Summary: wrong offset in IMAGE_DEBUG_DIRECTORY Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Optlink AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2012-06-18 20:43:44 PDT --- While tracking down an issue with dbghelp.dll I found that the AddressOfRawData offset in the IMAGE_DEBUG_DIRECTORY header is 4 bytes to small. http://msdn.microsoft.com/en-us/library/windows/desktop/ms680307(v=vs.85).aspx Either we need to add 4 to AddressOfRawData or we need to shift the CodeView information and reduce PointerToRawData accordingly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8264] New: [std.conv.to] constructing conversion doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=8264
Summary: [std.conv.to] constructing conversion doesn't work
with alias this
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-06-18 22:28:24 PDT ---
from
http://forum.dlang.org/thread/mailman.1606.1340038410.24740.digitalmars-d-le...@puremagic.com#post-cetlbrtfhbtunchppikq:40forum.dlang.org
This kind conversions should be possible with std.conv.to.
import std.conv;
struct Wrap
{
string wrap;
alias wrap this;
}
void main()
{
Wrap[] y = to!(Wrap[])([foo, bar]); // shold work
}
If you can construct Wrap object with the syntax Wrap(foo),
std.conv.to runs 'conversion by construction'.
And if S is convertible to T, std.conv.to!(T[])(S[] source) runs
'element-wise array conversion'.
As a result, string[] to Wrap[] will be converted.
...but, this does not work in 2.060head, it is a bug.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8264] [std.conv.to] constructing conversion doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=8264
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-18 22:45:19
PDT ---
Is it really bug? What if you have
struct Wrap
{
string wrap;
int i;
double d;
string s;
alias wrap this;
}
Should Wrap(foo) create the same thing as Wrap(foo, int.init, double.init,
string.init)? Or should it not work? Maybe it should work, but it seems a bit
funny to me to create a Wrap from just a string considering that the alias
doesn't define how to initialize the rest of the object.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
