[Issue 8221] typeof(null) rejected as return type for covariant overrides
http://d.puremagic.com/issues/show_bug.cgi?id=8221 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-13 23:05:57 PDT --- (In reply to comment #2) Why should this compile? What is the compelling reason? typeof(null) is a subtype of array/class/pointer types. By return type covariance rule, B.foo should be able to override A.foo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8220] invalid function call not detected during semantic analysis
http://d.puremagic.com/issues/show_bug.cgi?id=8220 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-06-14 00:27:28 PDT --- Created an attachment (id=1115) failing test case -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8226] Global lambda assign to const/immutable
http://d.puremagic.com/issues/show_bug.cgi?id=8226 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-14 00:36:07 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c6eac5a257644cfef0b29fe2c23f61bc339cfb69 fix Issue 8226 - Global lambda assign to const/immutable https://github.com/D-Programming-Language/dmd/commit/a6fc13b1101efb66b00391343d837ac0cbcf9620 Merge pull request #999 from 9rnsr/fix8226 Issue 8226 - Global lambda assign to const/immutable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8221] typeof(null) rejected as return type for covariant overrides
http://d.puremagic.com/issues/show_bug.cgi?id=8221 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-06-14 00:39:47 PDT --- (In reply to comment #3) typeof(null) is a subtype of array/class/pointer types. By return type covariance rule, B.foo should be able to override A.foo. Since A is not a base class of null, I do not think this is valid. foo could return B, and that will work, because A is a base class of B. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8220] invalid function call not detected during semantic analysis
http://d.puremagic.com/issues/show_bug.cgi?id=8220
--- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-06-14 00:51:28 PDT ---
(In reply to comment #3)
Created an attachment (id=1115) [details]
failing test case
I think this test case is not correct code.
(From test case)
alias typeof(Length*Length) Area;
alias typeof(Length*Area) Volume;
alias typeof(Mass/Volume) Density;
alias typeof(Length*Mass/Time/Time) Force;
alias typeof(1/Time) Frequency;
alias typeof(Force/Area) Pressure;
alias typeof(Force*Length)Energy;
alias typeof(Energy/Time) Power;
alias typeof(Time*Current)Charge;
alias typeof(Power/Current) Voltage;
alias typeof(Charge/Voltage) Capacitance;
alias typeof(Voltage/Current) Resistance;
alias typeof(1/Resistance)Conductance;
alias typeof(Voltage*Time)MagneticFlux;
alias typeof(MagneticFlux/Area) MagneticFluxDensity;
alias typeof(MagneticFlux/Current)Inductance;
alias typeof(Intensity*UnitLess) LuminousFlux;
alias typeof(LuminousFlux/Area) Illuminance;
As far as I know, normal expressions cannot take Type as their operands, even
if it is defined by operator overloading.
struct S { void opMul(S s){} }
S + S; // this is INVALID code
This rule should be applied even in typeof expression, then
typeof(Length*Length) must be invalid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #11 from Manu turkey...@gmail.com 2012-06-14 01:26:44 PDT ---
(In reply to comment #7)
Suppose I made this work:
-
template ParameterTypeTuple(alias foo)
I.e. the default argument is propagated to the tuple. Will that work for you?
That would be amazing, though the argument names are equally important too.
I'm pretty sure someone already had a pull request somewhere to add a __traits
for the arg names.
(In reply to comment #9)
Or better:
PT[1] getDefault(PT[1..2] a) { return a[0]; }
pragma(msg, typeof(bar));
pragma(msg, PT[1]);
PT[1] boo(PT[1..2] a) { return a[0]; }
It's not clear to me what those pragma's would produce. Just to reiterate,
type, name and default args are all important details about the parameter list.
I can't do without all 3.
If I'm generating functions to wrap other functions, the new function has to
have matching parameter names. If I use nonsense names, then auto-complete
pop-ups will just show nonsense to the user, and the user wouldn't know what
you're supposed to pass to the function.
(In reply to comment #10)
I think that's a better solution, so I'm marking this as won't fix.
I agree, although perhaps you shouldn't mark this as won't-fix, since I think
it's still somewhat of a bug. Just drop the priority?
func.stringof ideally shouldn't produce a syntactically incorrect string
regardless. Fortunately, with your proposed changes, I won't depend on it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6197] std.traits.isImplicitlyConvertible returns some wrong results.
http://d.puremagic.com/issues/show_bug.cgi?id=6197 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-14 02:20:55 PDT --- Already fixed in 2.060head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7360] Predicate templates in std.traits should consider alias this
http://d.puremagic.com/issues/show_bug.cgi?id=7360 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-06-14 02:24:02 PDT --- This issue has been fixed by the pull: https://github.com/D-Programming-Language/phobos/pull/488 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5548] Efficient std.conv.to conversions
http://d.puremagic.com/issues/show_bug.cgi?id=5548 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-06-14 02:33:25 PDT --- I agree with Steven. If you want to represent objects with output range of characters, you can use std.format.formatValue family directly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8237] New: Error message with _error_ when using failed type inference in template parameter
http://d.puremagic.com/issues/show_bug.cgi?id=8237
Summary: Error message with _error_ when using failed type
inference in template parameter
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2012-06-14 02:49:29 PDT ---
template warg(R)
{
enum bool warg = false;
}
void blarg()
{
int r = void;
auto s = r ~ xxx;
bool bbb = warg!(typeof(s));
}
bug.d(11): Error: incompatible types for ((r) ~ (xxx)): 'int' and 'string'
bug.d(12): Error: expression warg!(_error_) is void and has no value
It shouldn't be trying to instantiate the template at all.
Another consequence of this is that CTFE can get called on a ScopeExp, which
doesn't make sense (and the ScopeExp is an invalid template). This happens for
example when compiling std.range with -debug -unittest.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8226] Global lambda assign to const/immutable
http://d.puremagic.com/issues/show_bug.cgi?id=8226 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 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 --- Comment #12 from Walter Bright bugzi...@digitalmars.com 2012-06-14 07:14:50 PDT --- (In reply to comment #11) (In reply to comment #7) I.e. the default argument is propagated to the tuple. Will that work for you? That would be amazing, though the argument names are equally important too. I'm pretty sure someone already had a pull request somewhere to add a __traits for the arg names. I looked, but didn't see it. pragma(msg, typeof(bar)); pragma(msg, PT[1]); It's not clear to me what those pragma's would produce. They're just informative. If I'm generating functions to wrap other functions, the new function has to have matching parameter names. If I use nonsense names, then auto-complete pop-ups will just show nonsense to the user, and the user wouldn't know what you're supposed to pass to the function. Ok, so it's a user-experience issue, not one where it does not work. Let me think about it. It's important that I understand what issue you're trying to solve. (In reply to comment #10) I think that's a better solution, so I'm marking this as won't fix. I agree, although perhaps you shouldn't mark this as won't-fix, since I think it's still somewhat of a bug. Just drop the priority? func.stringof ideally shouldn't produce a syntactically incorrect string regardless. It doesn't produce a syntactically incorrect string, it produces one that semantically won't compile in the context it is in. I reiterate that the problem is which names are in scope and which aren't? It's just an impractical problem, and making it work in one case will break others. It's a game of whack-a-mole. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8220] invalid function call not detected during semantic analysis
http://d.puremagic.com/issues/show_bug.cgi?id=8220 klickverbot c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #5 from klickverbot c...@klickverbot.at 2012-06-14 07:36:35 PDT --- (In reply to comment #3) Created an attachment (id=1115) [details] failing test case I also think this is genuinely invalid code: Besides the fact that there isn't really a good reason, grammar-wise, for the code to compile, allowing it as a special case in typeof() would create exactly the same sort of problems with is(typeof()) as with __traits(compiles, …) in the original report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8238] New: regression: templates can create ghost fields
http://d.puremagic.com/issues/show_bug.cgi?id=8238
Summary: regression: templates can create ghost fields
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-14 07:36:12 PDT ---
DMD 2.059:
struct S{ template t(){ int t; } }
void main(){
S s,t;
writeln(t.t!());// 0
s.t!()=256;
writeln(t.t!(), ,s.t!()); // 1 256
}
The code is illegal, but accepted.
I remember that such code used to be rejected.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 --- Comment #13 from Manu turkey...@gmail.com 2012-06-14 08:03:11 PDT --- (In reply to comment #12) (In reply to comment #11) (In reply to comment #7) pragma(msg, typeof(bar)); pragma(msg, PT[1]); It's not clear to me what those pragma's would produce. They're just informative. What I mean is, I don't quite follow the syntax of your proposal. What would be the output of the pragmas you illustrate? Ie, what _exactly_ does PT contain? I just understand you intend that it will somehow contain the type AND default arg expression (but not the name?), rather than just the type as it does now... how does that work in practise syntactically? If I'm generating functions to wrap other functions, the new function has to have matching parameter names. If I use nonsense names, then auto-complete pop-ups will just show nonsense to the user, and the user wouldn't know what you're supposed to pass to the function. Ok, so it's a user-experience issue, not one where it does not work. Let me think about it. It's important that I understand what issue you're trying to solve. In this case, only that aspect (the names) is a UX issue, the rest is mechanical. The default args are required in the wrapper I generate or calling code won't compile. That said, I wouldn't be satisfied with the solution if I didn't have access to the names, and I would have to persist with tedious parsing FuncType.stringof to gather them again... There are other cases where I have needed the names too. In mixins inserted into a function body; without a trait that can give the argument names, there's no way to refer to function arguments from within the mixin. I have run in to this situations numerous times, but I've worked around them at the cost of code complexity since there was no solution at the time. I'm just saying, access to the parameter names is also important if you're going to the effort of being able to introspect the default arg expressions. It doesn't produce a syntactically incorrect string, it produces one that semantically won't compile in the context it is in. I reiterate that the problem is which names are in scope and which aren't? It's just an impractical problem, and making it work in one case will break others. It's a game of whack-a-mole. I'd imagine that what should actually be expected, is the expression relative to the scope where it was declared. Ie, the expression as it was written in the declaration. Nothing else makes any sense by my logic. But this is obviously not particularly important. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8239] New: PIC always enabled on OSX
http://d.puremagic.com/issues/show_bug.cgi?id=8239 Summary: PIC always enabled on OSX Product: D Version: D2 Platform: All OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2012-06-14 08:14:55 PDT --- DMD should support -fPIC like on other platforms and other OSX compilers. It seems that the backend currently only supports PIC code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8199] stack is not aligned in finally block
http://d.puremagic.com/issues/show_bug.cgi?id=8199 d...@dawgfoto.de changed: What|Removed |Added Keywords||patch Severity|normal |major --- Comment #1 from d...@dawgfoto.de 2012-06-14 08:42:49 PDT --- https://github.com/D-Programming-Language/dmd/pull/988 This bug affects all calls from a finally block that require an aligned stack. The optimization is also a huge performance hog. Abusing return as indirect jump always incurs a branch misprediction. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8240] New: std.algorithm.joiner and empty inputRangeObject
http://d.puremagic.com/issues/show_bug.cgi?id=8240
Summary: std.algorithm.joiner and empty inputRangeObject
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: lomerei...@gmail.com
--- Comment #0 from Artem Tarasov lomerei...@gmail.com 2012-06-14 08:47:47
PDT ---
Segmentation fault:
import std.range, std.algorithm;
void main()
{
assert(equal(joiner([inputRangeObject()]), ));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6774] ICE(glue.c) totym gagged forward reference error
http://d.puremagic.com/issues/show_bug.cgi?id=6774
Roman D. Boiko r...@d-coding.com changed:
What|Removed |Added
CC||r...@d-coding.com
--- Comment #5 from Roman D. Boiko r...@d-coding.com 2012-06-14 10:22:27 PDT
---
struct S(T) {
pure nothrow static void foo(immutable(T) data) {}
pure nothrow static void foo(ref immutable(T) data) {}
}
unittest {
immutable a = 2.0f;
S!float.foo(a);
}
compiler is run with the following flags:
-m64 -w -debug -gc -fPIC -unittest
on Ubuntu 12.10 x64.
Result:
Error: 2 is not an lvalue
dmd: glue.c:1114: virtual unsigned int Type::totym(): Assertion `0' failed.
Aborted (core dumped)
make: *** [build/client] Error 134
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6774] ICE(glue.c) totym gagged forward reference error
http://d.puremagic.com/issues/show_bug.cgi?id=6774 --- Comment #6 from Roman D. Boiko r...@d-coding.com 2012-06-14 10:26:37 PDT --- (In reply to comment #5) compiler is run with the following flags: -m64 -w -debug -gc -fPIC -unittest Actually, -unittest is enough, other flags don't affect the result. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8241] New: cannot use template function literal as default alias argument
http://d.puremagic.com/issues/show_bug.cgi?id=8241
Summary: cannot use template function literal as default alias
argument
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-14 10:36:16 PDT ---
DMD 2.059:
auto exec(alias a=function(x)=x,T...)(T as){return a(as);}
mixin exec!(function(x)=x, int); // ok
void main(){exec(2);} // error
The code should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8242] New: cannot use template function literals at module scope
http://d.puremagic.com/issues/show_bug.cgi?id=8242
Summary: cannot use template function literals at module scope
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-14 10:42:26 PDT ---
DMD 2.059:
auto exec(alias a,T...)(T as){return a(as);}
mixin exec!(x=x, int); // error
The code should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8243] cannot initialize tuple with an element at module scope
http://d.puremagic.com/issues/show_bug.cgi?id=8243 timon.g...@gmx.ch changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from timon.g...@gmx.ch 2012-06-14 11:49:46 PDT --- (with DMD 2.059, the code fails to compile, but it is valid.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8243] New: cannot initialize tuple with an element at module scope
http://d.puremagic.com/issues/show_bug.cgi?id=8243
Summary: cannot initialize tuple with an element at module
scope
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-14 11:49:10 PDT ---
template TypeTuple(T...){ alias T TypeTuple; }
TypeTuple!(int,int) a = 12;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8246] New: type tuple fields pollute the linker namespace
http://d.puremagic.com/issues/show_bug.cgi?id=8246
Summary: type tuple fields pollute the linker namespace
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-14 12:10:44 PDT ---
DMD 2.059:
template TypeTuple(T...){ alias T TypeTuple; }
TypeTuple!int x;
int _x_field_0;
static assert(x[0].mangleof != _x_field_0.mangleof); // fail
The static assertion should pass.
(if the assertion is commented out, the code generates a linker error.)
The compiler must use a reserved identifier, for example
__tuple_x_field_0 instead of _x_field_0
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8247] New: Inconsistent behaviour of randomSample depending on whether a random number generator is specified
http://d.puremagic.com/issues/show_bug.cgi?id=8247 Summary: Inconsistent behaviour of randomSample depending on whether a random number generator is specified Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: joseph.wakel...@webdrake.net --- Comment #0 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2012-06-14 12:27:53 PDT --- Created an attachment (id=1116) Working minimal example illustrating the inconsistencies described. The randomSample function in std.random can be called with or without specifying a random number generator to use. If no RNG is specified, then each lazy evaluation of the sample evaluates differently, i.e. if you do sample1 = randomSample(iota(0, 100), 5); writeln(sample1); writeln(sample1); writeln(sample1); you will get 3 different samples. Conversely, if a random number generator is specified, you will get 3 times the same result: sample2 = randomSample(iota(0, 100), 5, Random(unpredictableSeed)); writeln(sample2); writeln(sample2); writeln(sample2); Note that the seeding of the RNG is important, because if an already-existing RNG is provided to create multiple different samples, they will evaluate identically, e.g. sample3 = randomSample(iota(0, 100), 5, rndGen); writeln(sample3); sample4 = randomSample(iota(0, 100), 5, rndGen); writeln(sample4); sample5 = randomSample(iota(0, 100), 5, rndGen); writeln(sample5); ... will produce the same output 3 times. This happens because the RNG passed to randomSample is copied rather than used by reference. These inconsistencies lead to a lot of potential confusion and sources of bugs. So, first of all, we need a firm decision on how the lazy evaluation of RandomSample should behave -- should it (1) always evaluate to the same sample, or (2) always evaluate to a different sample? ... and depending on the answer, we then need to address how to specify and seed an RNG for RandomSample. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8247] Inconsistent behaviour of randomSample depending on whether a random number generator is specified
http://d.puremagic.com/issues/show_bug.cgi?id=8247 --- Comment #1 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2012-06-14 12:35:44 PDT --- Online discussion on this: http://forum.dlang.org/thread/4fd735eb.70...@webdrake.net -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8247] Inconsistent behaviour of randomSample depending on whether a random number generator is specified
http://d.puremagic.com/issues/show_bug.cgi?id=8247 jens.k.muel...@gmx.de changed: What|Removed |Added CC||jens.k.muel...@gmx.de --- Comment #2 from jens.k.muel...@gmx.de 2012-06-14 13:41:13 PDT --- I opt for the returning the same sample (option 1). I want the sample to stay the same. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8239] PIC always enabled on OSX
http://d.puremagic.com/issues/show_bug.cgi?id=8239 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-06-14 18:44:19 PDT --- It's supposed to always be on, as OSX code always must be pic. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8240] std.algorithm.joiner and empty inputRangeObject
http://d.puremagic.com/issues/show_bug.cgi?id=8240 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-14 21:54:44 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/cbd1e63026da31176a21b140a911fc53337ff09c Updated changelog for fix for issue 8240. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8240] std.algorithm.joiner and empty inputRangeObject
http://d.puremagic.com/issues/show_bug.cgi?id=8240 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8240] std.algorithm.joiner and empty inputRangeObject
http://d.puremagic.com/issues/show_bug.cgi?id=8240 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-06-14 22:11:36 PDT --- Merged pull request: https://github.com/D-Programming-Language/phobos/pull/632 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
