with
-checkaction=context
* https://issues.dlang.org/show_bug.cgi?id=22374
[REG 2.093] 'import std;' with -checkaction=context causes
link error
* https://issues.dlang.org/show_bug.cgi?id=22902
dmd 2.099 regression: unittest -checkaction=context and
import std.regex causes link er
g.cgi?id=22374
[REG 2.093] 'import std;' with -checkaction=context causes link
error
* https://issues.dlang.org/show_bug.cgi?id=22902
dmd 2.099 regression: unittest -checkaction=context and import
std.regex causes link error
Does `dmd -allinst ...` help in your case?
passes. Can anybody reproduce this?
https://run.dlang.io/is/GYDUBz
File an issue, I'd say. The worst thing that can happen is
that someone flags it as a duplicate.
Issue 22902 - dmd 2.099 regression: unittest
-checkaction=context and import std.regex causes link error
(edit)
://run.dlang.io/is/GYDUBz
File an issue, I'd say. The worst thing that can happen is that
someone flags it as a duplicate.
Issue 22902 - dmd 2.099 regression: unittest -checkaction=context
and import std.regex causes link error (edit)
https://issues.dlang.org/show_bug.cgi?id=22902
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
https://run.dlang.io/is/GYDUBz
File an issue, I'd say. The worst thing that can
zstack.d:
```
module zstack;
import std.stdio: writeln;
void bar (int [] i)
{
writeln ("i: ", i);
}
unittest {
int [] arr;
bar (arr);
}
```
zrepo.d:
```
module parser;
import std.regex;
import zstack;
```
```
$ dmd -g -i -unittest -checkaction=context -main -run zrepro
2>&1 | ddem
On 12/3/19 12:15 PM, James Blachly wrote:
On 11/17/19 7:15 PM, Steven Schveighoffer wrote:
On 11/17/19 10:45 AM, James Blachly wrote:
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[str
On 11/17/19 7:15 PM, Steven Schveighoffer wrote:
On 11/17/19 10:45 AM, James Blachly wrote:
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
On 11/17/19 10:45 AM, James Blachly wrote:
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
There's a subtle removing of the shared from the
TL;DR druntime regression?
https://gist.github.com/jblachly/78c5762bbfea65b09e7a1417ad763019
---
Our team has an older codebase that compiled fine up until frontend
version 2.087 (builds with 2.086.1). Now, compiler (DMD2 and LDC2)
complains about implicit conversion of shared(AA) to const
On Friday, August 16, 2019 2:16:31 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
>
> wrote:
> > Not being able to implicitly convert to const is a bit odd, but
> > arguably, nothing should ever be called on a shared AA anyway.
>
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safel
regression?
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safely, you have to protect
access to it with a mutex or
object.d(3417):
> Error: cannot implicitly convert expression aa of type
> shared(string[string]) to const(shared(string)[string])
> onlineapp.d(7): Error: template instance
> `object.keys!(shared(string[string]), shared(string), string)`
> error instantiating
>
> Before D 2.087 it
: template instance
`object.keys!(shared(string[string]), shared(string), string)`
error instantiating
Before D 2.087 it compiled - is this a regression?
On Friday, 16 March 2018 at 20:17:49 UTC, aberba wrote:
How will you test D code which makes calls to database to
detect bugs and regression. Unlike where you can inject data
like assert (2+1 == 3), database interfacing code will be
crazy... Or there's some mocking available for such
db. And some general queries... my worry has been adding a
> feature which might cause a regression in another rearly executed
> code...its feels like I have to test all features/rest calls after
> every major change. Don't know how others do this...when there's some
> tight coup
code has very complex
interdependencies, then it's going to be hard to test no matter
how you try.
My code logic is a mix of file uploads which leads to saving file
info into db. And some general queries... my worry has been
adding a feature which might cause a regression in another rearly
On Sun, Mar 18, 2018 at 07:51:18PM +, aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn
> > wrote:
> > > [...]
> >
> > The usual way I do this is to decouple the code
On Sunday, March 18, 2018 19:51:18 aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > The usual way I do this is to decouple the code from
On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via
Digitalmars-d-learn wrote:
[...]
The usual way I do this is to decouple the code from the real
database backend by templatizing the database driver. Then in
my unittest I can ins
On Friday, 16 March 2018 at 20:17:49 UTC, aberba wrote:
How will you test D code which makes calls to database to
detect bugs and regression. Unlike where you can inject data
like assert (2+1 == 3), database interfacing code will be
crazy... Or there's some mocking available for such
On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn wrote:
> How will you test D code which makes calls to database to detect bugs
> and regression. Unlike where you can inject data like assert (2+1 ==
> 3), database interfacing code will be crazy... Or there'
How will you test D code which makes calls to database to detect
bugs and regression. Unlike where you can inject data like assert
(2+1 == 3), database interfacing code will be crazy... Or there's
some mocking available for such cases. Especially when more
features are developed on top.
On Wednesday, February 28, 2018 14:28:47 bauss via Digitalmars-d-learn
wrote:
> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
> > done https://issues.dlang.org/show_bug.cgi?id=18539
>
> I would argue that isn't a regression and that you __should__ use
> the .
I would say it is a still regression, but I agree with you, that it should
not work on the first place.
On Wed, Feb 28, 2018 at 3:28 PM, bauss via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
>
&
On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
done https://issues.dlang.org/show_bug.cgi?id=18539
I would argue that isn't a regression and that you __should__ use
the .get and that it's not a workaround, because nullable's
shouldn't be treated like that t
done https://issues.dlang.org/show_bug.cgi?id=18539
Yes it is a regression, please fill a bug report
On Wed, Feb 28, 2018 at 2:16 PM, drug via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> https://run.dlang.io/is/HJxtvw
>
> ```
> import std.stdio, std.typecons, std.math;
> void main()
> {
>
https://run.dlang.io/is/HJxtvw
```
import std.stdio, std.typecons, std.math;
void main()
{
auto foo = nullable(2.0);
auto bar = nullable(2.0);
assert (foo.approxEqual(bar));
}
```
Comiling gives the following:
Up to 2.067.1: Failure with output:
-
onlineapp.d(4): Error: unde
the dependency
is not pre-compiled as a static library. It worked fine
before.
I guess a mangle problem ?
Yes and quite old...apparently it's more a 2.074.x regression.
i'm digging right now.
digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1)
is untestable.
digger: Ther
, Stefan Koch
wrote:
On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote:
I have a simple program that only compiles if the
dependency is not pre-compiled as a static library. It
worked fine before.
I guess a mangle problem ?
Yes and quite old...apparently it's more a 2.074.x
regre
, Basile B. wrote:
I have a simple program that only compiles if the
dependency is not pre-compiled as a static library. It
worked fine before.
I guess a mangle problem ?
Yes and quite old...apparently it's more a 2.074.x regression.
i'm digging right now.
digg
worked fine
before.
I guess a mangle problem ?
Yes and quite old...apparently it's more a 2.074.x regression.
i'm digging right now.
digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is
untestable.
digger: There are only untestable commits left to bisect.
digger: The first
old...apparently it's more a 2.074.x regression.
i'm digging right now.
s.d
import/iz/memory.d -Iimport
---
and tell me what do you think: regression or not ?
I guess a mangle problem ?
md samples/dictionnary_suffixarray.d lib/iz.a -Iimport >
ddemangle
#on the other hand, this works...
dub samples/dictionnary_suffixarray.d <<< "q"
#or even this...
dmd samples/dictionnary_suffixarray.d import/iz/strings.d
import/iz/memory.d -Iimport
---
and tell me what do you think: regression or not ?
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote:
The error is: "cannot take address of ref return of this.foo()
in @safe function bar".
Maybe a bugfix in safety system? Should it go through deprecation
process?
On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer
wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen
wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
For the record, the current
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen
wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
For the record, the current list of regressions caused by DIP1000
https://issues.dlang.org
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
s.bar();
}
```
The error is: "cannot take address of ref return of this.foo() in
@safe function bar".
Is this a compiler regression, or is it a bug in the D code?
https://issues.dlang.org/show_bug.cgi?id=17213
Thanks,
Johan
On Thursday, 16 February 2017 at 23:15:09 UTC, Johan Engelen
wrote:
Hi all,
`isNumeric!string` no longer works like it did in 2.071 when
both std.string and std.traits are imported.
https://issues.dlang.org/show_bug.cgi?id=17190
Hi all,
`isNumeric!string` no longer works like it did in 2.071 when both
std.string and std.traits are imported.
This code no longer compiles with 2.072:
```d
// RUN: dmd -c test.d
import std.string;
import std.traits;
void foo()
{
static if (isNumeric!string) {}
}
```
The error is (
Dne 8.4.2016 v 14:56 Steven Schveighoffer via Digitalmars-d-learn napsal(a):
On 4/8/16 2:08 AM, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree
On 4/7/16 11:55 AM, Steven Schveighoffer wrote:
Please file a bug report, not sure why this happened.
I filed it for you:
https://issues.dlang.org/show_bug.cgi?id=15897
-Steve
On 4/8/16 2:08 AM, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump through
this hoop:
void foo(Cat cat)
On Friday, 8 April 2016 at 08:26:11 UTC, Daniel Kozak wrote:
On Friday, 8 April 2016 at 06:08:38 UTC, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven
Schveighoffer wrote:
Wow, totally agree with you. Compiler shouldn't make you jump
through this hoop:
void foo(Cat cat)
{
Anima
On Friday, 8 April 2016 at 06:08:38 UTC, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer
wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump
through this h
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer
wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump
through this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.cr
On 4/6/16 11:10 AM, Andre wrote:
Hi,
With 2.071 following coding does not compile anymore and somehow I feel
it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I want to
call the method
create within the class Animal for cat.
On Wednesday, 6 April 2016 at 19:22:44 UTC, Daniel Kozak wrote:
This should not compile. Cat cant access create because it is
private. Ok
it can access it but only if you move cat into same module as
animal
Dne 6. 4. 2016 17:16 napsal uživatel "Andre via
Digitalmars-d-learn" <
digitalmars-d-le
This should not compile. Cat cant access create because it is private. Ok
it can access it but only if you move cat into same module as animal
Dne 6. 4. 2016 17:16 napsal uživatel "Andre via Digitalmars-d-learn" <
digitalmars-d-learn@puremagic.com>:
> Hi,
>
> With 2.071 following coding does not c
On Wednesday, 6 April 2016 at 19:01:58 UTC, Craig Dillabaugh
wrote:
On Wednesday, 6 April 2016 at 15:10:45 UTC, Andre wrote:
clip
Not so up to date on D's OOP stuff, but don't you want create()
to be protected, not private. You can typically access a
private method through a base class, whi
On Wednesday, 6 April 2016 at 15:10:45 UTC, Andre wrote:
Hi,
With 2.071 following coding does not compile anymore and
somehow I feel it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I
want to call the method
create within
Hi,
With 2.071 following coding does not compile anymore and somehow
I feel it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I
want to call the method
create within the class Animal for cat.
Is the error message "no prope
V Thu, 14 Jan 2016 17:32:47 +
NX via Digitalmars-d-learn napsáno:
> Please explain.
Regression: something works before does not work anymore
Bug: something does not work as expected (regression is one type of bug)
Please explain.
On Wednesday, 9 September 2015 at 01:35:26 UTC, Sebastiaan Koppe
wrote:
Thanks for your advice. But that is not what I asked for.
The question was, why doesn't this work anymore with the latest
(2.068.0 and 2.068.1) compiler:
```
auto ls =
File("../languages.json","r").byLineCopy().joiner.p
"r").byLineCopy().joiner.parseJSON();
```
It should. Right?
I just ran into this as well. This seems like a regression.
On Tuesday, 8 September 2015 at 07:12:52 UTC, FreeSlave wrote:
On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
wrote:
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.par
On Tuesday, September 08, 2015 07:12:50 FreeSlave via Digitalmars-d-learn wrote:
> On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
> wrote:
> > Fixed it by changing into:
> >
> > ```
> > import std.conv : text;
> > string json =
> > File("../languages.json","r").byLineCopy().
On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
wrote:
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
Why would you read file by line and then merge a
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
Dammit, i am on windows, DMD32 D Compiler v2.068.0
This used to work in older compiler (might have been v2.067 or
v2.066, not older).
```
#!rdmd
import std.stdio;
import std.json;
import std.algorithm;
void main() {
auto ls =
File("../languages.json","r").byLineCopy().joiner.parseJSON();
}
```
Error: c:\D\dmd2\windows\bin\..\..\src\phobos\
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote:
I tried rebuilding my knowledge graph project at
https://github.com/nordlow/justd/tree/master/knet
with DMD 2.068 and it seems like we have a regression in
std.traits: EnumMembers:
[...]
It builds without errors nor warnings on
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote:
Try cloning https://github.com/nordlow/justd/tree
Should be:
git clone https://github.com/nordlow/justd
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote:
I tried rebuilding my knowledge graph project at
https://github.com/nordlow/justd/tree/master/knet
Should be, https://github.com/nordlow/justd.
I tried rebuilding my knowledge graph project at
https://github.com/nordlow/justd/tree/master/knet
with DMD 2.068 and it seems like we have a regression in
std.traits: EnumMembers:
/usr/include/dmd/phobos/std/traits.d(3432,21): Error: template
instance std.traits.EnumMembers!(Lang
I reported this as a regression
https://issues.dlang.org/show_bug.cgi?id=14582
The std.batmanip bigEndianToNative has a regression where the
slice range doesn't work with variables (only literals).
Is the syntax incorrect or is this a regression in dmd?
Using this main.d:
import std.bitmanip;
int main(string args[])
{
auto datain = new ubyte[16];
// this s
On Sunday, 6 July 2014 at 22:03:21 UTC, hane wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception("");
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): E
On Sunday, 6 July 2014 at 13:04:35 UTC, Marc Schütz wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception("");
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception("");
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception("");
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error
```
void bar()
{
throw new Exception("");
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
s my memory failing me, or
> >>>was this a deliberate change at some point? Perhaps a regression?
> >>
> >>It's not a regression, it's a locked-in design mistake. Write it
> >>like this and try again:
> >>
> >>foreach (dchar d; "你好
On Thursday, 26 December 2013 at 05:39:26 UTC, Lionello Lunesu
wrote:
On 12/26/13, 11:58, bearophile wrote:
Lionello Lunesu:
I could have sworn this used to work. Is my memory failing
me, or was
this a deliberate change at some point? Perhaps a regression?
It's not a regression, i
On 12/26/13, bearophile wrote:
> You have to explain such things in the main D newsgroup. D.learn
> newsgroup is not fit for such requests.
There have already been a million of these threads, it's worth doing a
search as there's probably lots of answers there.
Lionello Lunesu:
Yeah, that's what I ended up doing. But D being D, the default
should be safe and correct.
I feel we could take this breaking change since it would not
silently change the code to do something else.
You have to explain such things in the main D newsgroup. D.learn
newsgroup
On 12/26/13, 11:58, bearophile wrote:
Lionello Lunesu:
I could have sworn this used to work. Is my memory failing me, or was
this a deliberate change at some point? Perhaps a regression?
It's not a regression, it's a locked-in design mistake. Write it like
this and try again:
fore
Lionello Lunesu:
I could have sworn this used to work. Is my memory failing me,
or was this a deliberate change at some point? Perhaps a
regression?
It's not a regression, it's a locked-in design mistake. Write it
like this and try again:
foreach (dchar d; "你好")
Bye,
bearophile
ot;, so that confirms the type is not deduced as "dchar".
I could have sworn this used to work. Is my memory failing me, or was
this a deliberate change at some point? Perhaps a regression?
L.
(389): Error: this for _expand_field_0 needs to be type Tuple
not type Foo
Am I doing something wrong or is this a regression? If I do any of the
following the code will compile:
* Move the static-if outside of "foo"
* Replace "NEW_ARGS.length" with "args.length&quo
On 2013-09-22 15:49, simendsjo wrote:
In 2.063.2, (T!int).stringof == "T!(int)". In current head, it's "T!int".
Even (T!(int)).stringof == "T!int".
So is this a regression bug or a bugfix?
Apparently you shouldn't rely on the format of .stringof. See t
On Sunday, 22 September 2013 at 13:50:00 UTC, simendsjo wrote:
In 2.063.2, (T!int).stringof == "T!(int)". In current head,
it's "T!int".
Even (T!(int)).stringof == "T!int".
So is this a regression bug or a bugfix?
Added a ticket so it doesn't
In 2.063.2, (T!int).stringof == "T!(int)". In current head, it's
"T!int".
Even (T!(int)).stringof == "T!int".
So is this a regression bug or a bugfix?
Ali Çehreli:
The best thing to do is to forget about the -property
switch. I did about a year ago and never looked back. :)
But the whole issue of -property was a partial failure for the D
community and D designers. Several threads, hundreds of posts,
and I see no clear directives or solutio
On Friday, May 31, 2013 08:27:19 Ali Çehreli wrote:
> I think it is the same issue with non-templated functions. The best
> thing to do is to forget about the -property switch. I did about a year
> ago and never looked back. :)
Given the most recent discussions on @property, I think that it's a fo
On 05/31/2013 07:32 AM, rmc wrote:
> It is very common to use a function template without the call "()"
> expecting that it will be called.
Non-templated functions too.
> However with the latest compilers
> hibernated only compiles when one leaves out the -property dmd command
> line option.
I
Hi all,
Not sure if this is a bug so thought I'd post here.
It is very common to use a function template without the call
"()" expecting that it will be called. However with the latest
compilers hibernated only compiles when one leaves out the
-property dmd command line option.
The call:
ge
On Sunday, 3 February 2013 at 02:28:26 UTC, timotheecour wrote:
here goes:
http://d.puremagic.com/issues/show_bug.cgi?id=9444
please see my added comment in 9444 regarding capturing std err
instead of displaying it.
actually the new std.process pull request
(http://forum.dlang.org/thread/k5u
here goes:
http://d.puremagic.com/issues/show_bug.cgi?id=9444
please see my added comment in 9444 regarding capturing std err
instead of displaying it.
On 2/3/13, timotheecour wrote:
> Isn't there a unittest to test this?
The only unittest is unfortunately pretty bad:
unittest
{
auto x = shell("echo wyda");
}
Please feel free to file a bug:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
The doc for std.process.shell says "If the process could not be
started or exits with an error code, throws an exception."
However on OSX I'm having a different kind of behavior.
Isn't there a unittest to test this?
---
import std.process;
import std.stdio;
void main(){
shell("asfasfas
"Don" wrote in message
news:i2q0un$2hu...@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> It still leaves the question though, "Why isn't that working in D2? Bug
>> or legitimate reason?".
>>
>> Jonathan suggested it was deliberate because of the hidden "this"
>> parameter, but I'm not convin
Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:i2pvvi$2g8...@digitalmars.com...
"bearophile" wrote in message
news:i2p4iq$p...@digitalmars.com...
Nick Sabalausky:
That's because my original example accidentally made Foo an
uninstantiated
class template, so the compiler never
"Nick Sabalausky" wrote in message
news:i2pvvi$2g8...@digitalmars.com...
> "bearophile" wrote in message
> news:i2p4iq$p...@digitalmars.com...
>> Nick Sabalausky:
>>> That's because my original example accidentally made Foo an
>>> uninstantiated
>>> class template, so the compiler never bother
"bearophile" wrote in message
news:i2p4iq$p...@digitalmars.com...
> Nick Sabalausky:
>> That's because my original example accidentally made Foo an
>> uninstantiated
>> class template, so the compiler never bothered to check the semantics...
>
> Surely here there is no shortage of ways I can pai
1 - 100 of 106 matches
Mail list logo
