[Issue 9633] compiles trait wrongly returns true even when object method call actually does not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9633 --- Comment #2 from github-bugzi...@puremagic.com 2013-03-06 23:55:17 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/85c896a7514c72e8ff9bd7b546e3aa1257cb70ff [REG2.063a] fix Issue 9633 - compiles trait wrongly returns true even when object method call actually does not compile Improve isNeedThisScope https://github.com/D-Programming-Language/dmd/commit/0679c4c31ba78853873933324c69cd90e7714d15 Merge pull request #1722 from 9rnsr/fix9633 [REG2.063a] Issue 9633 - compiles trait wrongly returns true even when object method call actually does not compile -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9633] compiles trait wrongly returns true even when object method call actually does not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9633 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 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Martin Nowak c...@dawg.eu 2013-03-07 03:43:50 PST --- Can you provide any links or information? After searching around quite a lot I get the impression there is no native TLS support in OSX. The only thing I could find are related to __emutls_get_address calls created by certain clang/gcc version. At least the newest gcc (build 5658) doesn't support __thread out of the box. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9660] New: [meta] Not able to debug on Windows starting from ~10 MiB executable size
http://d.puremagic.com/issues/show_bug.cgi?id=9660 Summary: [meta] Not able to debug on Windows starting from ~10 MiB executable size Product: D Version: D2 Platform: All OS/Version: Windows Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: verylonglogin@gmail.com Depends on: 6144 --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 15:09:10 MSK --- Starting from ~10 MiB executable (with debug info included) OPTLINK Issue 6144 is triggered so one have to develop further without debug info which is really pity expecially as it starts when the project is already has medium size. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6144] Unexpected OPTLINK Termination at EIP=00428DA3
http://d.puremagic.com/issues/show_bug.cgi?id=6144 --- Comment #10 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 15:11:43 MSK --- Filled meta issue 9660 about debugging problem caused by this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size
http://d.puremagic.com/issues/show_bug.cgi?id=9660 --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 15:10:12 MSK --- Some magic like separating a part of the project into a library may or may not help. Eliminating use of templates often helps. E.g. one should always append `.array()` after (finite) range based operations and then pass an array to a regular (non-templated) function instead of passing Voldemort types to a templated function. Another workaround is temporary commenting out some functions which uses templates (e.g. from `std.algorithm`) to debug other functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444
--- Comment #13 from bearophile_h...@eml.cc 2013-03-07 04:22:27 PST ---
(In reply to comment #12)
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/57b770ed49379c5af726d23356e0f75818a3f859
Issue 7444 - Require [] for array copies too
https://github.com/D-Programming-Language/dmd/commit/ba1009c5561b51b8f18d9c869fde9bd45cb7ebc7
Merge pull request #702 from 9rnsr/fix7444
Issue 7444 - Require [] for array copies too
I have tried this change, and now the first test case of this ER:
int[100] foo() {
int[100] a;
return a;
}
void main() {
int[10_000] a, b;
auto c = new int[10_000];
a = 1;
a = b;
a = c;
auto d = foo();
}
gives a ICE:
temp.d(8): Warning: explicit element-wise assignment (a)[] = 1 is better than a
= 1
temp.d(10): Warning: explicit element-wise assignment (a)[] = (c)[] is better
than a = c
Assertion failure: '0' on line 1193 in file 'glue.c'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476
--- Comment #2 from Jacob Carlborg d...@me.com 2013-03-07 04:34:32 PST ---
Right, I forgot about this. This is some information for a couple of post I
wrote in the newgroups:
Original code: http://pastebin.com/UKb6etWD
Disassembly with TLS: http://pastebin.com/nkdnE9w6
Disassembly without TLS: http://pastebin.com/vuvEBWWH
Object dump with TLS: http://pastebin.com/PqpPw56a
Object dump without TLS: http://pastebin.com/ki6atzEm
The source code for the dynamic linker on Mac OS X 10.7+ with the TLS handling:
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalHelpers.s
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalVariables.c
A description of what's basically happening in the source code above:
I've done some investigation. Currently DMD inserts a call to the
__tls_get_addr function when accessing a TLS variable. This is implemented in
druntime.
In Mac OS X 10.7 it works similar but instead of inserting a call to
__tls_get_addr there's a struct looking like this (written in D) :
struct TLVDescriptor
{
void* function (TLVDescriptor*) thunk;
size_t key;
size_t offset;
}
The dynamic linker will iterate all loaded images and extract the section
containing the TLS data. I guess this section consists of a list of
TLVDescriptor*. The dynamic linker will set the thunk to a function
tlv_get_addrs, implemented in assembly in the dynamic linker. It will set the
key to a key created by pthread_key_create. It will also map the image with
this key. This key is same for all TLVDescriptor of a given image.
Instead of calling __tls_get_addr I think that the compiler will need to call
the thunk passing in the TLVDescriptor itself to the thunk.
The tlv_get_addrs function will then extract the key and from that key it can
get the image the address belongs to.
Does that make any sens? Is that something the DMD could do, that is call the
thunk instead of __tls_get_addr.?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444
--- Comment #14 from bearophile_h...@eml.cc 2013-03-07 04:58:19 PST ---
(In reply to comment #13)
gives a ICE:
Smaller test case:
void main() {
int[1] a;
a = 1;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444
--- Comment #15 from Kenji Hara k.hara...@gmail.com 2013-03-07 05:14:27 PST
---
(In reply to comment #14)
(In reply to comment #13)
gives a ICE:
Smaller test case:
void main() {
int[1] a;
a = 1;
}
What version and compiler switch do you use? I cannot reproduce the ICE.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5662] Optlink 8.00.11 hangs
http://d.puremagic.com/issues/show_bug.cgi?id=5662 --- Comment #2 from yebblies yebbl...@gmail.com 2013-03-08 00:59:27 EST --- Might be more likely if the reporter was added to the bug report -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #7 from yebblies yebbl...@gmail.com 2013-03-08 01:25:47 EST ---
I agree with Walter, nothing should be ctfe'd unless the code explicitly asks
for it.
However...
If the contracts are fairly simple, like in this function:
int func(int a, int b)
in
{
assert(a + b != 12);
}
out(result)
{
assert(result = 20);
}
body
{
return 15;
}
It would be possible for the compiler to use constant-folding (not ctfe) to
verify the assertions can pass, in the pre- and post-conditions.
eg.
func(3, 9); Error: function call func(3, 9) cannot pass precondition
or
Error: 'return 15' cannot pass postcondition
This can be done by converting precondition bodies to expressions then
const-folding them. Non-trivial, but possible.
This only makes sense if we define violating a function's precondition as
invalid code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9009] allow foreach without identifier
http://d.puremagic.com/issues/show_bug.cgi?id=9009
--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07
07:08:24 PST ---
(In reply to comment #3)
I think this is a simple nice idea. There is no point in requiring to name a
variable that will not used. It's like in function signatures:
void foo(int, int y) { }
He meant:
void foo(int, int) { }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476 --- Comment #3 from Martin Nowak c...@dawg.eu 2013-03-07 07:05:20 PST --- (In reply to comment #2) Right, I forgot about this. This is some information for a couple of post I wrote in the newgroups: Original code: http://pastebin.com/UKb6etWD Disassembly with TLS: http://pastebin.com/nkdnE9w6 Disassembly without TLS: http://pastebin.com/vuvEBWWH How did you compile the code? Did you have to use a certain compiler and version? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5140] Add __FUNCTION__, __PRETTY_FUNCTION__, and __MODULE__
http://d.puremagic.com/issues/show_bug.cgi?id=5140 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476 --- Comment #4 from Jacob Carlborg d...@me.com 2013-03-07 08:23:27 PST --- (In reply to comment #3) How did you compile the code? Did you have to use a certain compiler and version? $ clang --version Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix Mac OS X 10.8.2 Xcode Version 4.6 (4H127) The exact version used by Xcode would is: $ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix But they give the same code. This is compiled for 32bit, if you haven't already figured that out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476 --- Comment #5 from Jacob Carlborg d...@me.com 2013-03-07 08:26:39 PST --- GCC shipped with the same version of Xcode cannot build the code: $ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I guess Apple doesn't really care about GCC anymore. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9476] Support native TLS on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=9476 --- Comment #6 from Jacob Carlborg d...@me.com 2013-03-07 08:33:49 PST --- This thread might be of interest as well. It's from the Clang mailing list: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-November/025571.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9661] New: LockingTextWriter should increment file handle reference count
http://d.puremagic.com/issues/show_bug.cgi?id=9661 Summary: LockingTextWriter should increment file handle reference count Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: lomerei...@gmail.com --- Comment #0 from Artem Tarasov lomerei...@gmail.com 2013-03-07 08:44:25 PST --- Its behaviour is inconsistent with byLine() and byChunk() - which keep File struct internally instead of FILE* pointer. Compare: auto lines = File(/tmp/file.txt).byLine(); writeln(lines); // works auto writer = File(/tmp/file.txt, w+).lockingTextWriter; writer.put(123); // fails - the file is already closed! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4814] rdmd: Doesn't rebuild when using -of and turning an -L linker option on or off
http://d.puremagic.com/issues/show_bug.cgi?id=4814 --- Comment #3 from Andrei Alexandrescu and...@erdani.com 2013-03-07 09:30:07 PST --- https://github.com/D-Programming-Language/tools/pull/49 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4847] std.algorithm.topN documentation
http://d.puremagic.com/issues/show_bug.cgi?id=4847 --- Comment #4 from github-bugzi...@puremagic.com 2013-03-07 10:39:52 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/29e043d4616a7d21fbdbd8102b95d01494750759 Fix Issue 4847 - std.algorithm.topN documentation Converted unittest into an example. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4847] std.algorithm.topN documentation
http://d.puremagic.com/issues/show_bug.cgi?id=4847 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Andrei Alexandrescu and...@erdani.com 2013-03-07 10:41:05 PST --- Thanks for following through. Refixed, please reopen if needed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444 --- Comment #16 from bearophile_h...@eml.cc 2013-03-07 12:10:52 PST --- (In reply to comment #15) What version and compiler switch do you use? I cannot reproduce the ICE. I am using the GIT head compiler, I have downloaded and compiled dmd few hours ago, after this patch was merged. I am on Windows 32 bit, and I have compiled the code with: dmd -wi test.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906 --- Comment #8 from bearophile_h...@eml.cc 2013-03-07 12:15:52 PST --- (In reply to comment #7) This can be done by converting precondition bodies to expressions then const-folding them. Non-trivial, but possible. Thank you for the note, that seems better than having nothing. This only makes sense if we define violating a function's precondition as invalid code. This seems OK. What are possible downsides of this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9662] New: rdmd should have a test suite
http://d.puremagic.com/issues/show_bug.cgi?id=9662 Summary: rdmd should have a test suite Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: and...@erdani.com --- Comment #0 from Andrei Alexandrescu and...@erdani.com 2013-03-07 13:12:35 PST --- Currently there's no test suite for rdmd, and it has happened that changes to rdmd broke existing behaviors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9662] rdmd should have a test suite
http://d.puremagic.com/issues/show_bug.cgi?id=9662 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #1 from David Nadlinger c...@klickverbot.at 2013-03-07 13:19:42 PST --- A test suite for rdmd would indirectly also be helpful for LDC development: Currently, ldmd2 does not quite handle output file placement in the same way as DMD (thus failing its purpose as a drop-in replacement), but it is unclear what needs to be changed. Having a set of test cases for the various options would make that much easier, and I imagine an rdmd test suite might quite naturally contain a number of them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9574] Diagnostic for old use of 'alias this = that' should be informative
http://d.puremagic.com/issues/show_bug.cgi?id=9574 --- Comment #2 from github-bugzi...@puremagic.com 2013-03-07 13:51:48 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9b3ecfb6a0286b2a2c856d3b2fdec01a9491d74f Fixes Issue 9574 - Better diagnostic on old 'alias this = that' syntax. https://github.com/D-Programming-Language/dmd/commit/1e9511b94cc0cfacc7058fe5cad02a597e8dae2e Merge pull request #1685 from AndrejMitrovic/Fix9574 Issue 9574 - Better diagnostic on old 'alias this = that' syntax. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4814] rdmd: Doesn't rebuild when using -of and turning an -L linker option on or off
http://d.puremagic.com/issues/show_bug.cgi?id=4814 --- Comment #4 from github-bugzi...@puremagic.com 2013-03-07 14:19:45 PST --- Commits pushed to master at https://github.com/D-Programming-Language/tools https://github.com/D-Programming-Language/tools/commit/a76dc63b2a662d5ba21ed8a55f6b56cce158900d Fix issue 4814 https://github.com/D-Programming-Language/tools/commit/e14e0378375d1bb586871f8e66cc501dac64a7e1 Merge pull request #49 from andralex/4814 Fix Issue 4814 - rdmd: Doesn't rebuild when using -of and turning an -L linker option on or off -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4814] rdmd: Doesn't rebuild when using -of and turning an -L linker option on or off
http://d.puremagic.com/issues/show_bug.cgi?id=4814 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||andrej.mitrov...@gmail.com Component|Phobos |DMD Resolution||FIXED AssignedTo|and...@erdani.com |nob...@puremagic.com OS/Version|Linux |All --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07 14:20:55 PST --- Can we get an RDMD component added to bugzilla? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9574] Diagnostic for old use of 'alias this = that' should be informative
http://d.puremagic.com/issues/show_bug.cgi?id=9574 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 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444 --- Comment #17 from Kenji Hara k.hara...@gmail.com 2013-03-07 15:41:56 PST --- (In reply to comment #16) (In reply to comment #15) What version and compiler switch do you use? I cannot reproduce the ICE. I am using the GIT head compiler, I have downloaded and compiled dmd few hours ago, after this patch was merged. I am on Windows 32 bit, and I have compiled the code with: dmd -wi test.d Thanks. -w option does not reproduce it, but -wi does. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9663] New: [REG2.063a] ICE caused by issue 7444 change.
http://d.puremagic.com/issues/show_bug.cgi?id=9663
Summary: [REG2.063a] ICE caused by issue 7444 change.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-03-07 16:55:45 PST ---
From: http://d.puremagic.com/issues/show_bug.cgi?id=7444#c13
I have tried this change, and now the first test case of this ER:
int[100] foo() {
int[100] a;
return a;
}
void main() {
int[10_000] a, b;
auto c = new int[10_000];
a = 1;
a = b;
a = c;
auto d = foo();
}
gives a ICE:
temp.d(8): Warning: explicit element-wise assignment (a)[] = 1 is better than a
= 1
temp.d(10): Warning: explicit element-wise assignment (a)[] = (c)[] is better
than a = c
Assertion failure: '0' on line 1193 in file 'glue.c'
From: http://d.puremagic.com/issues/show_bug.cgi?id=7444#c14
Smaller test case:
void main() {
int[1] a;
a = 1;
}
From: http://d.puremagic.com/issues/show_bug.cgi?id=7444#c16
What version and compiler switch do you use? I cannot reproduce the ICE.
I am using the GIT head compiler, I have downloaded and compiled dmd few hours
ago, after this patch was merged.
I am on Windows 32 bit, and I have compiled the code with:
dmd -wi test.d
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9663] [REG2.063a] ICE caused by issue 7444 change.
http://d.puremagic.com/issues/show_bug.cgi?id=9663 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-03-07 16:59:12 PST --- https://github.com/D-Programming-Language/dmd/pull/1727 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Kenji Hara k.hara...@gmail.com 2013-03-07 17:00:31 PST --- (In reply to comment #17) (In reply to comment #16) (In reply to comment #15) What version and compiler switch do you use? I cannot reproduce the ICE. I am using the GIT head compiler, I have downloaded and compiled dmd few hours ago, after this patch was merged. I am on Windows 32 bit, and I have compiled the code with: dmd -wi test.d Thanks. -w option does not reproduce it, but -wi does. OK, I opened a new report bug 9663 for the regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size
http://d.puremagic.com/issues/show_bug.cgi?id=9660 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07 18:33:01 PST --- Why did you open this if it's about Issue 6144? Keep issues about actual bugs and not discussions about other issues. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
--- Comment #9 from yebblies yebbl...@gmail.com 2013-03-08 13:33:42 EST ---
(In reply to comment #8)
(In reply to comment #7)
This can be done by converting precondition bodies to expressions then
const-folding them. Non-trivial, but possible.
Thank you for the note, that seems better than having nothing.
This only makes sense if we define violating a function's precondition as
invalid code.
This seems OK. What are possible downsides of this?
struct S(int a)
{
void fun(int b) in { assert(a != b); } body {}
}
void main()
{
foreach(i; TypeTuple!(1, 2, 3, 4))
{
auto s = S!i();
if (i != 4)
s.fun(4);
}
}
This code would error 'cannot call S.fun with b == 4' etc even though S.fun
never actually gets called with 4.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2486] taking address of slice rvalue should not be allowed
http://d.puremagic.com/issues/show_bug.cgi?id=2486 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||ga...@mail.ru --- Comment #10 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07 18:50:48 PST --- *** Issue 9651 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 9651] Returning a newly-created slice by reference
http://d.puremagic.com/issues/show_bug.cgi?id=9651 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07 18:50:47 PST --- Issue 2486 fixed this. *** This issue has been marked as a duplicate of issue 2486 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9588] format prints context pointer for struct
http://d.puremagic.com/issues/show_bug.cgi?id=9588
--- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07
19:18:48 PST ---
(In reply to comment #4)
Hmm. Using __traits(allMembers, S) seems to indicate that the field name is
'this'. Since 'this' is a reserved keyword, that may be safer to check for
than
assuming that the compiler will always put it last.
This won't work out that easy. The code in format uses .tupleof to get to the
values, but .tupleof and allMembers return different results, for example:
void main()
{
struct S { int x; this(int) { } }
}
allMembers:
tuple(x, __ctor, this)
.tupleof:
tuple(0, S(0).this)
So the indexes won't match. Since my new isNested trait was pulled, and
assuming the context pointer is last, I could do:
immutable tupleLen = val.tupleof.length;
foreach (i, e; val.tupleof)
{
// skip printing context pointer
static if (__traits(isNested, T) i+i == tupleLen) { }
}
It's hard to tell whether this will be safe.
Another idea is to change how .tupleof works internally (to remove exposing the
context pointer), but this might be a bad idea, serialization might probably
require it as well as other code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
--- Comment #11 from bearophile_h...@eml.cc 2013-03-07 19:29:40 PST ---
(In reply to comment #10)
If the pre-condition analysis (constant folding) is done after a normal step
of
dead branch removal, then maybe that error will not be shown.
Currently it doesn't happen, and this generates an error (you need a static
if to make the error go away):
import std.typetuple;
void main() {
int[4] a;
foreach (i; TypeTuple!(1, 2, 3, 4)) {
if (i != 4)
a[i]++;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
--- Comment #10 from bearophile_h...@eml.cc 2013-03-07 19:25:12 PST ---
(In reply to comment #9)
struct S(int a)
{
void fun(int b) in { assert(a != b); } body {}
}
void main()
{
foreach(i; TypeTuple!(1, 2, 3, 4))
{
auto s = S!i();
if (i != 4)
s.fun(4);
}
}
This code would error 'cannot call S.fun with b == 4' etc even though S.fun
never actually gets called with 4.
I see, thank you for the answer.
If the pre-condition analysis (constant folding) is done after a normal step of
dead branch removal, then maybe that error will not be shown.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5906] Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
--- Comment #12 from yebblies yebbl...@gmail.com 2013-03-08 14:33:58 EST ---
(In reply to comment #10)
I see, thank you for the answer.
If the pre-condition analysis (constant folding) is done after a normal step
of
dead branch removal, then maybe that error will not be shown.
Currently it doesn't happen, and this generates an error (you need a static
if to make the error go away):
That is an interesting point.
I seriously doubt that would be enough anyway, I think you would need full flow
analysis to work out which paths can actually be taken.
Another good example is this:
int div(int a, int b)
in
{
assert(b != 0, Division by zero!);
}
body
{
return a / b;
}
void main(string[] args)
{
auto i = 3 / 0; // Fails at compile time
auto j = div(3, 0); // Would fail at compile time if this was implemented
}
So maybe it is acceptable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9663] [REG2.063a] ICE caused by issue 7444 change.
http://d.puremagic.com/issues/show_bug.cgi?id=9663 --- Comment #2 from github-bugzi...@puremagic.com 2013-03-07 21:05:55 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/978aeaec777c7445634476877eb088db3b9d46bc fix Issue 9663 - [REG2.063a] ICE caused by issue 7444 change. https://github.com/D-Programming-Language/dmd/commit/40424680afd81ada506334550ef63c5fd76265b8 Merge pull request #1727 from 9rnsr/fix9663 Issue 9663 - [REG2.063a] ICE caused by issue 7444 change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9663] [REG2.063a] ICE caused by issue 7444 change.
http://d.puremagic.com/issues/show_bug.cgi?id=9663 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 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size
http://d.puremagic.com/issues/show_bug.cgi?id=9660 --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-08 08:49:14 MSK --- (In reply to comment #2) Why did you open this if it's about Issue 6144? Keep issues about actual bugs and not discussions about other issues. IMHO it's a separate and valuable issue which will be fixed if Issue 6144 will but may be (probably) fixed also in a different way. Yes, fill free to mark it INVALID if you sure I'm obviously incorrect. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5450] no match for implicit super() call in constructor
http://d.puremagic.com/issues/show_bug.cgi?id=5450 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
