http://d.puremagic.com/issues/show_bug.cgi?id=8196
Summary: Compiler pages are missing -nofloat flag
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #20 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 11:54:40 MSD ---
(In reply to comment #19)
I honestly don't understand why much in the way of examples are needed.
OK. I have written some examples. Are they too
http://d.puremagic.com/issues/show_bug.cgi?id=7878
--- Comment #5 from github-bugzi...@puremagic.com 2012-06-04 01:39:01 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
http://d.puremagic.com/issues/show_bug.cgi?id=5358
--- Comment #3 from github-bugzi...@puremagic.com 2012-06-04 01:38:55 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6642
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #22 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 13:07:21 MSD ---
(In reply to comment #21)
Why would you be marking a function as pure if it can access global state? The
compiler would flag that unless you
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #23 from timon.g...@gmx.ch 2012-06-04 02:22:54 PDT ---
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #11)
Pointers may only access their own memory blocks, therefore
http://d.puremagic.com/issues/show_bug.cgi?id=7937
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #24 from timon.g...@gmx.ch 2012-06-04 02:41:16 PDT ---
(In reply to comment #22)
`strlen` is now pure (marked by Andrei Alexandrescu) and it can access global
state once used with non-zero-ended string. I just made situation
http://d.puremagic.com/issues/show_bug.cgi?id=7878
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #25 from klickverbot c...@klickverbot.at 2012-06-04 03:07:52 PDT
---
I am partly playing Devil's advocate here, but:
(In reply to comment #23)
This is
why i suggested above that only dereferencing a pointer should be allowed
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #26 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:19:22
PDT ---
I'd actually argue that the line Pure functions are functions that produce the
same result for the same arguments should be removed from the spec.
http://d.puremagic.com/issues/show_bug.cgi?id=3702
Denis Shelomovskij verylonglogin@gmail.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #27 from klickverbot c...@klickverbot.at 2012-06-04 03:38:12 PDT
---
(In reply to comment #26)
While the origin and original motivation for pure in D was to enable
optimizations based on functional purity (multiple calls to the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #29 from timon.g...@gmx.ch 2012-06-04 03:39:52 PDT ---
(In reply to comment #25)
I am partly playing Devil's advocate here, but:
(In reply to comment #23)
This is
why i suggested above that only dereferencing a pointer
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #28 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:39:33
PDT ---
https://github.com/D-Programming-Language/d-programming-language.org/pull/128
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #30 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 03:42:40
PDT ---
I think you've provided a good explanation of the high-level design of the
pure keyword, more than once, but it seems that you are missing that this
http://d.puremagic.com/issues/show_bug.cgi?id=8197
Summary: phobos\win32.mak missing -Idruntime\import
Product: D
Version: unspecified
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #31 from klickverbot c...@klickverbot.at 2012-06-04 06:18:02 PDT
---
(In reply to comment #30)
pure doesn't restrict pointers in any way shape or form. That's an
@safe/@trusted/@system issue, and is completely orthogonal to pure.
http://d.puremagic.com/issues/show_bug.cgi?id=8185
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
---
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #33 from klickverbot c...@klickverbot.at 2012-06-04 06:43:32 PDT
---
(In reply to comment #32)
That's correct. You should not expect *any* optimizations from weakly pure
functions. The ONLY purpose of weakly pure functions is to
http://d.puremagic.com/issues/show_bug.cgi?id=7646
josvanu...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #34 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 19:08:08 MSD ---
(In reply to comment #33)
(In reply to comment #32)
That's correct. You should not expect *any* optimizations from weakly pure
functions. The
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #35 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 19:18:33 MSD ---
For Jonathan M Davis: here (as before) when I say optimization I mean
doesn't behave such way that can be optimized which means doesn't behave
such
http://d.puremagic.com/issues/show_bug.cgi?id=8197
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #36 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 08:45:00
PDT ---
int f(size_t) pure;
__gshared int tmp;
void g(size_t, ref int dummy = tmp) pure;
void h(size_t a, size_t b) pure
{
int res = f(a);
g(b);
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #37 from klickverbot c...@klickverbot.at 2012-06-04 09:03:18 PDT
---
(In reply to comment #34)
[…] strong unsafe pure functions […]
Please note that @safe-ty of a function has nothing to do with purity. Yes in a
@system/@trusted
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #38 from art.08...@gmail.com 2012-06-04 09:08:38 PDT ---
(In reply to comment #23)
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12)
(In reply to comment #11)
Pointers may only access their
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #39 from klickverbot c...@klickverbot.at 2012-06-04 09:13:14 PDT
---
(In reply to comment #38)
BTW, is my foo() above @safe? According to the compiler here - it is.
If so, please open a new issue – this is clearly a bug.
--
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #40 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 20:27:24 MSD ---
(In reply to comment #36)
int f(size_t) pure;
__gshared int tmp;
void g(size_t, ref int dummy = tmp) pure;
void h(size_t a, size_t b)
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #41 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-04 09:35:33
PDT ---
void g(size_t p, ref size_t) pure
{
++*cast(int*) p;
}
You're casting a size_t to a pointer. That's breaking the type system. The
assertion is
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #42 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 20:52:56 MSD ---
(In reply to comment #41)
void g(size_t p, ref size_t) pure
{
++*cast(int*) p;
}
You're casting a size_t to a pointer. That's breaking
http://d.puremagic.com/issues/show_bug.cgi?id=6579
--- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:01:16 PDT ---
(In reply to comment #7)
Oh, and i just noticed the suggestion in this report that static fields should
not be accessible via an instance - no, that
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #43 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:30:19 PDT ---
(In reply to comment #42)
It isn't and here is the point! It's explicitly stated that when I'm casting
away const and than modify date the result is
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #44 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:45:33 PDT ---
(In reply to comment #7)
In general response to this bug, I'm unsure how pointers should be treated by
the optimizer. My gut feeling is the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #45 from klickverbot c...@klickverbot.at 2012-06-04 10:51:45 PDT
---
(In reply to comment #44)
Still thinking about the rest of the proposal, but:
[…] or @trusted functions […]
If a @trusted function accepts a pointer, it must
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #46 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
10:59:49 PDT ---
(In reply to comment #45)
(In reply to comment #44)
Still thinking about the rest of the proposal, but:
[…] or @trusted functions […]
If a
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #47 from Denis Shelomovskij verylonglogin@gmail.com
2012-06-04 22:13:05 MSD ---
(In reply to comment #43)
The compiler does not assume the worst, it assumes the reasonable, until
you tell it otherwise. In other words, no
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #48 from klickverbot c...@klickverbot.at 2012-06-04 11:24:10 PDT
---
(In reply to comment #46)
(In reply to comment #45)
If a @trusted function accepts a pointer, it must _under no circumstances_
access anything except for the
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #49 from art.08...@gmail.com 2012-06-04 11:29:39 PDT ---
As this discussions was mostly about what *should* be happening, I decided to
see what actually *is* happening right now.
It seems that the compiler will only optimize based
http://d.puremagic.com/issues/show_bug.cgi?id=8197
--- Comment #2 from simendsjo simend...@gmail.com 2012-06-04 11:33:52 PDT ---
(In reply to comment #1)
Please be more specific. The autotester is passing on all platforms. This
sounds like an issue with your environment or installation. But
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #50 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:35:27 PDT ---
(In reply to comment #47)
Common! System language must have strict rights. You just have said that D is
JavaScript.
A systems language is very strict
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #51 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:48:22 PDT ---
(In reply to comment #48)
(In reply to comment #46)
(In reply to comment #45)
If a @trusted function accepts a pointer, it must _under no
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #52 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
11:51:14 PDT ---
(In reply to comment #49)
It seems that the compiler will only optimize based on pureness if a
function
takes an 'immutable T*' argument, even
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #53 from klickverbot c...@klickverbot.at 2012-06-04 12:12:16 PDT
---
(In reply to comment #51)
(In reply to comment #48)
Here, calling gun needs to be safe under _any_ circumstances.
No, it does not. Once you use @trusted,
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #54 from klickverbot c...@klickverbot.at 2012-06-04 12:14:40 PDT
---
(In reply to comment #52)
This is a bug, both should be optimized equally:
void foo(immutable int * _param) pure
{
immutable(int)* param = _param; //
http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #55 from Steven Schveighoffer schvei...@yahoo.com 2012-06-04
13:34:50 PDT ---
(In reply to comment #53)
(In reply to comment #51)
(In reply to comment #48)
Here, calling gun needs to be safe under _any_ circumstances.
http://d.puremagic.com/issues/show_bug.cgi?id=8198
Summary: Nested lambda inference doesn't work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
48 matches
Mail list logo