[Issue 14128] wrong alias
https://issues.dlang.org/show_bug.cgi?id=14128 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 14128] New: wrong alias
https://issues.dlang.org/show_bug.cgi?id=14128
Issue ID: 14128
Summary: wrong alias
Product: D
Version: D1 D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: vlevenf...@gmail.com
The line alias b = that.object seems to alias this.object:
struct TrivialFunctor (T)
{
T object;
int opCmp ()(auto ref TrivialFunctor!T that)
{
alias a = this.object;
alias b = that.object;
import std.stdio;
writeln (this.object, ` `, that.object); // 1 2
writeln (a, ` `, b); // 1 1
writeln ((this.object) == (that.object)); // false, ok
writeln (a == b); // true?!
stdout.flush;
if (a b)
return -1;
else if (a b)
return 1;
else return 0;
}
auto opBinary (string op)(auto ref TrivialFunctor!T that)
{
return TrivialFunctor (mixin(q{this.object } ~ op ~ q{ that.object}));
}
}
auto trivial_functor (T)(T value)
{
return TrivialFunctor!T (value);
}
void main ()
{
TrivialFunctor!int a = 1.trivial_functor, b = 2.trivial_functor;
auto c = a + b;
assert (a b b c); // fails
}
--
[Issue 13651] Writing Unicode text with console code page 65001 (UTF-8) may fail
https://issues.dlang.org/show_bug.cgi?id=13651 mzfh...@foxmail.com changed: What|Removed |Added CC||mzfh...@foxmail.com --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #7 from Orvid King blah38...@gmail.com --- It is a valid bug, just not sure of the cause yet. --
[Issue 14108] template object.get cannot deduce function from argument types
https://issues.dlang.org/show_bug.cgi?id=14108 --- Comment #4 from Timothee Cour timothee.co...@gmail.com --- But the argument $key to aa.get(key) doesn't need to be stored, it's just used to retrieve the value with that key if it's there (eg by computing a hash function on the key, which doesn't need key to be immutable). Am I misunderstanding something? --
[Issue 14087] @disable this hides static opCall
https://issues.dlang.org/show_bug.cgi?id=14087 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- (In reply to Kenji Hara from comment #2) Therefore compiler raises an error for the struct declaration. I agree. Such code looks pretty dubious anyway, I'm good with it being an error. --
[Issue 6400] opDispatch with WithStatement
https://issues.dlang.org/show_bug.cgi?id=6400 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||rob...@octarineparrot.com --- Comment #2 from yebblies yebbl...@gmail.com --- *** Issue 9808 has been marked as a duplicate of this issue. *** --
[Issue 9808] with statement does not work with opDispatch
https://issues.dlang.org/show_bug.cgi?id=9808 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from yebblies yebbl...@gmail.com --- *** This issue has been marked as a duplicate of issue 6400 *** --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 Puneet Goel pun...@coverify.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #6 from Puneet Goel pun...@coverify.org --- I am reopening the issue. It is not invalid. I know an assertion should not be called from a destructor, I am doing that to avoid printing multiple messages. The real bug is that I am getting unexpected value of element _foo in the destructor. --
[Issue 14108] template object.get cannot deduce function from argument types
https://issues.dlang.org/show_bug.cgi?id=14108 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- (In reply to Timothee Cour from comment #2) But why can't a char[] be used here though? Seems to me it would be safe to allow that? Because the associative array does not store a copy of the key, it stores the key. If the key is mutable, then it could change, and the associative array's data structure then becomes corrupt. --
[Issue 14093] [REG2.065] __traits(compiles, cast(Object)(tuple)) is true even if it doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=14093 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- The error: foo2.d(8): Error: e2ir: cannot cast __tup1850.__expand_field_0 of type int to type object.Object foo2.d(8): Error: e2ir: cannot cast __tup1850.__expand_field_1 of type int to type object.Object is coming from the glue layer. The __traits(compiles, ) does not get that far. The error check needs to be moved up into the front end to fix it. --
[Issue 12153] Ternary operator on static array lvalues creates copy
https://issues.dlang.org/show_bug.cgi?id=12153 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bdb30977e7084d1c496c7b386203af8dd33eea0d Move fix Issue 12153 to frontend https://github.com/D-Programming-Language/dmd/commit/e62c349db2f20f8ea709314bcbca16540c6cfc35 Merge pull request #4062 from ibuclaw/fix12153 Move fix Issue 12153 to frontend --
[Issue 13952] change in struct ctor lowering generates excessive init code
https://issues.dlang.org/show_bug.cgi?id=13952 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Summary|change in struct ctor |change in struct ctor |lowering triggers codegen |lowering generates |bug |excessive init code Severity|regression |normal --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- Changed to reflect your last comment. --
[Issue 14129] New: stdio.write crashed on window console with codepage 65001
https://issues.dlang.org/show_bug.cgi?id=14129
Issue ID: 14129
Summary: stdio.write crashed on window console with codepage
65001
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: mzfh...@foxmail.com
Created attachment 1474
-- https://issues.dlang.org/attachment.cgi?id=1474action=edit
test.json
windows console default codepage is 936,
it's show chinese char is uncorrect.
so i input the command chcp 65001 change the codepage .
then in most cases,it's works ok!
but write a special file,it's crashed.
import std.stdio;
import std.file;
int main(string[] argv)
{
auto s = readText(r.\test.json);
write(s); //crashed
return 0;
}
std.exception.ErrnoException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2113):
(No error)
0x00402998
0x00402901
0x00402897
0x00402881
0x004027AA
0x004040B3
0x00403FC9
0x00402AF3
0x776C1194 in BaseThreadInitThunk
0x779AB3F5 in RtlInitializeExceptionChain
0x779AB3C8 in RtlInitializeExceptionChain
Failed to flush stdout: No error
--
[Issue 14125] @trusted nested helper functions in std.file
https://issues.dlang.org/show_bug.cgi?id=14125 --- Comment #77 from Andrei Alexandrescu and...@erdani.com --- Thanks Steve for the nice summary! --
[Issue 10920] template instantiation order dependent link failure problem
https://issues.dlang.org/show_bug.cgi?id=10920 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #7 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4384 --
[Issue 14125] @trusted nested helper functions in std.file
https://issues.dlang.org/show_bug.cgi?id=14125 John Colvin john.loughran.col...@gmail.com changed: What|Removed |Added CC||john.loughran.colvin@gmail. ||com --- Comment #75 from John Colvin john.loughran.col...@gmail.com --- Walter and Andrei are completely right here. If you can't factor out the @system code to a function providing a truly safe interface (marked with @trusted), then the code clearly depends on its surrounding context to make it safe. So *all* of that code needs to be manually verified with the same scrutiny, together with the core bit that actually appeared to be @system. It becoming a maintenance nightmare is just unveiling the true difficulty of safely using @system code, as opposed to papering over it. It might become good practice in robust @trusted code to add static asserts to ensure that changes to @system (explicit or inferred) further down the call tree aren't accidentally missed. static assert(isTrusted!func) or similar. --
[Issue 14125] @trusted nested helper functions in std.file
https://issues.dlang.org/show_bug.cgi?id=14125
--- Comment #74 from Walter Bright bugzi...@digitalmars.com ---
(In reply to hsteoh from comment #68)
Then there's Andrei's PR that contains a 50+-line @trusted function. I had a
headache trying to figure out whether it was truly @trusted -- it's wa
too big to be adequately reviewed in a satisfactory way. And this review
effort has to be incurred every single time somebody so much as touches a
single line in that function, because @trusted disables all compiler safety
checks and therefore we can never be too sure whether the change has
introduced subtle breakage in safety.
See my review of std.array.join() upthread. The idea that one could mark a
function with an unsafe interface as @trusted and thereby avoid having to check
the rest of the code for safety is destroyed by that example. The rest was
correct, but could not be checked for safety by the compiler. It had to be
reviewed. The @trusted workaround only provided an illusion of safety. No work
was avoided - extra work is caused because I no longer trust the code in
std.array and it all needs reviewing again.
I propose a review rule - functions of the following patterns will be
automatically rejected by reviewers:
1. any function that trivially wraps a call to an @system function so it can be
marked as @trusted. For example:
@trusted void* trustedMalloc(size_t n) { return malloc(n); }
2. any function that is a trivial wrapper around an operation that would
otherwise be flagged as unsafe, for example:
@trusted void* incPtr(void* p) { return p + 1; }
--
[Issue 7151] [CTFE] cannot compare classes with ==
https://issues.dlang.org/show_bug.cgi?id=7151 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/8a3ea8160d940dc22916cbd3e18e5eb19ece8b28 mostly fix Issue 7151 - [CTFE] cannot compare classes with == Essentially, copy the implementation of opEquals into object.di. Comparison of TypeInfo objects still doesn't work. Seems to be a dmd issue. https://github.com/D-Programming-Language/druntime/commit/8c13443c436a453e01c6319f74e2e6d54f44a547 Merge pull request #916 from NilsBossung/7151 mostly fix Issue 7151 - [CTFE] cannot compare classes with == --
[Issue 7151] [CTFE] cannot compare classes with ==
https://issues.dlang.org/show_bug.cgi?id=7151 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13952] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952
--- Comment #4 from Martin Nowak c...@dawg.eu ---
struct X86Imm
{
ulong imm;
}
struct X86Opnd
{
union
{
X86Reg reg;
X86Imm imm;
}
ubyte tag;
this(X86Reg r) { reg = r; }
}
struct X86Reg
{
/// Register type
ubyte type;
/// Register index number
ubyte regNo;
/// Size in bits
ushort size;
}
X86Opnd opnd(X86Reg reg)
{
return X86Opnd(reg);
}
Here is the asm that for the opnd function with 2.066.1
_D4bug24opndFS4bug26X86RegZS4bug27X86Opnd PROC
pushrbp ; _ 55
mov rbp, rsp; 0001 _ 48: 8B. EC
sub rsp, 32 ; 0004 _ 48: 83. EC, 20
lea rax, [rbp-20H] ; 0008 _ 48: 8D. 45, E0
xor rcx, rcx; 000C _ 48: 31. C9
mov qword ptr [rax], rcx; 000F _ 48: 89. 08
mov qword ptr [rax+8H], rcx ; 0012 _ 48: 89. 48, 08
mov rsi, rdi; 0016 _ 48: 89. FE
mov rdi, rax; 0019 _ 48: 89. C7
call_D4bug27X86Opnd6__ctorMFNcS4bug26X86RegZS4bug27X86Opnd; 001C _
E8, (rel)
mov rdx, qword ptr [rax+8H] ; 0021 _ 48: 8B. 50, 08
mov rax, qword ptr [rax]; 0025 _ 48: 8B. 00
mov rsp, rbp; 0028 _ 48: 8B. E5
pop rbp ; 002B _ 5D
ret ; 002C _ C3
_D4bug24opndFS4bug26X86RegZS4bug27X86Opnd ENDP
That's the same function now.
_D4bug24opndFS4bug26X86RegZS4bug27X86Opnd PROC
pushrbp ; _ 55
mov rbp, rsp; 0001 _ 48: 8B. EC
sub rsp, 32 ; 0004 _ 48: 83. EC, 20
xor eax, eax; 0008 _ 31. C0
mov dword ptr [rbp-18H], eax; 000A _ 89. 45, E8
mov dword ptr [rbp-14H], eax; 000D _ 89. 45, EC
xor ecx, ecx; 0010 _ 31. C9
mov byte ptr [rbp-10H], cl ; 0012 _ 88. 4D, F0
mov byte ptr [rbp-0FH], cl ; 0015 _ 88. 4D, F1
mov word ptr [rbp-0EH], ax ; 0018 _ 66: 89. 45, F2
mov edx, dword ptr [rbp-10H]; 001C _ 8B. 55, F0
mov dword ptr [rbp-20H], edx; 001F _ 89. 55, E0
mov byte ptr [rbp-18H], cl ; 0022 _ 88. 4D, E8
mov rsi, rdi; 0025 _ 48: 89. FE
lea rdi, [rbp-20H] ; 0028 _ 48: 8D. 7D, E0
call_D4bug27X86Opnd6__ctorMFNcS4bug26X86RegZS4bug27X86Opnd; 002C _
E8, (rel)
mov rdx, qword ptr [rax+8H] ; 0031 _ 48: 8B. 50, 08
mov rax, qword ptr [rax]; 0035 _ 48: 8B. 00
mov rsp, rbp; 0038 _ 48: 8B. E5
pop rbp ; 003B _ 5D
ret ; 003C _ C3
_D4bug24opndFS4bug26X86RegZS4bug27X86Opnd ENDP
Just focusing on the X86Opnd init code
lea rax, [rbp-20H]
xor rcx, rcx
mov qword ptr [rax], rcx
mov qword ptr [rax+8H], rcx
In the new code the 4 bytes at [rbp-1CH] are never initialized.
xor eax, eax
mov dword ptr [rbp-18H], eax
mov dword ptr [rbp-14H], eax
xor ecx, ecx
mov byte ptr [rbp-10H], cl
mov byte ptr [rbp-0FH], cl
mov word ptr [rbp-0EH], ax
mov edx, dword ptr [rbp-10H]
mov dword ptr [rbp-20H], edx
mov byte ptr [rbp-18H], cl
mov rsi, rdi
lea rdi, [rbp-20H]
Without a constructor it's the same for both dmd versions and also only
initializes the first union field of X86Opnd.
xor eax, eax
mov dword ptr [rbp-18H], eax
mov dword ptr [rbp-14H], eax
mov dword ptr [rbp-20H], edi
So this isn't really a regression and it was a bug in Higgs to rely on memory
compare.
I filed https://issues.dlang.org/show_bug.cgi?id=14107 to disallow default
comparison for structs with unions.
The amount of code generated for the constructor is still worrisome.
Especially the part that initializes X86Reg, because it initializes every field
individually, it constructs a temporary on the stack only to end up loading
zero into edx.
xor ecx, ecx
mov byte ptr [rbp-10H], cl
mov byte ptr [rbp-0FH], cl
mov word ptr
[Issue 6857] Precondition contract checks should be statically bound.
https://issues.dlang.org/show_bug.cgi?id=6857 --- Comment #89 from Andrei Alexandrescu and...@erdani.com --- To clarify: this issue is preapproved and is waiting for an implementation. --
[Issue 2500] template struct methods are left unresolved if imported from multiple modules
https://issues.dlang.org/show_bug.cgi?id=2500 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #7 from Kenji Hara k.hara...@gmail.com --- *** Issue 12099 has been marked as a duplicate of this issue. *** --
[Issue 14127] @trusted functions in std.array present unsafe interfaces
https://issues.dlang.org/show_bug.cgi?id=14127 --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- See https://issues.dlang.org/show_bug.cgi?id=14125 for rationale. --
[Issue 12099] Linkers Symbol Undefined of class-member instance in mutual dependent modules
https://issues.dlang.org/show_bug.cgi?id=12099 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com --- *** This issue has been marked as a duplicate of issue 2500 *** --
[Issue 10920] template instantiation order dependent link failure problem
https://issues.dlang.org/show_bug.cgi?id=10920
--- Comment #6 from Kenji Hara k.hara...@gmail.com ---
Sorry, the OP code was not correct. Precise test case is:
// foo.d
import bar;
void main() {
BitArray ba;
version(A) pragma(msg, typeof(ba.toString));
FormatSpec!char fs;
fs.func();
}
// bar.d
(same with in comment #0)
Command line:
$ dmd foo.d
-- OK
$ dmd -version=A foo.d
void()
OPTLINK (R) for Win32 Release 8.00.15
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
foo.obj(foo)
Error 42: Symbol Undefined
_D3bar18__T10FormatSpecTaZ10FormatSpec4funcMFNaNbNiNfZv
--- errorlevel 1
-- NG
FormatSpec!char is instantiated in both main() and BitArray.toString(). When
-version=A specified, the first instantiation happens in toString(), and its
codegen is wrongly judged to be unnecessary. And the second instantiation is
ignored and link-failure occurs.
It's definitely an issue that depends on the semantic analysis order.
--
[Issue 14125] @trusted nested helper functions in std.file
https://issues.dlang.org/show_bug.cgi?id=14125
--- Comment #76 from Steven Schveighoffer schvei...@yahoo.com ---
After reading this quite long thread (and I'm not going to CC myself because of
this), I want to summarize the viewpoints here. I think I see that everyone is
in slight agreement, but does not realize the other's *complete* viewpoint.
1. We all agree that a public function such as:
@trusted auto tmalloc(size_t x) {return malloc(x);}
Is no good, should never pass review.
2. There are occasions where inside a very lengthy function one wishes to be
called from @safe code, that a small portion of code which uses unsafe
functions, but in a safe manner, is needed. One would wish that in such a
function all the actual @safe calls are still checked by the compiler, and any
additions to the @safe portion should be checked for future maintainers.
3. A static nested function inside such a function is a license to commit sin
at will. In other words, such a function allows abuse by current and future
maintainers of that function. Therefore, even nested functions like the one in
point 1 above should probably be rejected. However, @trusted static nested
functions that do NOT leak memory details can be allowed.
4. A possible restriction (but not bulletproof) is to use an immediately-called
lambda to execute a trusted call. The issue here is that it won't be inlined.
Hence the desire to use static nested functions.
5. There is a general issue that adding valid @trusted calls inside a @safe
function is simply allowed in review without too much consideration for what it
means for future maintenance.
-
Now, point 4 is not bullet proof. Walter brought up a case where it is not, and
it's not hard to see it can be abused. When a @trusted call affects variables
inside a @safe function, it can mean that depending on the calls, any code that
then *uses* those variables, even in a safe way, is suspect. This means that
@trusted must extend to all those uses. Such a position makes for an incorrect
assumption about the entire function.
However, I think even worse is the idea that we add a static callable @trusted
function nested inside a @safe function, that can be called in an unsafe way.
Such a function cannot guarantee calls to it are safe. A lambda is much better
because review of its uses involves one line. But only if its details do not
leak!
So I would say, as a review requirement, we should limit internal @trusted
calls ONLY to lambdas, unless the static nested function does not leak memory
details. And inside those lambdas, the code should not affect any variables in
@safe code in a way that has the potential for abuse. I think this is doable,
because you can ask that question objectively by reading the one call. It
doesn't matter if code *doesn't* use that variable in an un@safe way, just the
*potential* of using it is enough to cause the review to fail.
There is the issue with not inlining lambdas. Tough. Get that fixed, it's not
worth corrupting memory to save some performance.
That's my $.02. I'll see about reviewing std.file.read and try and apply this
methodology to fix the issues.
--
[Issue 9567] Symbol Undefined linker error after separating project part into library
https://issues.dlang.org/show_bug.cgi?id=9567 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Sorry but .obj and .lib files are useless to find compiler issue. Is this still reproduce with 2.066, 2.066.1, or git-head? --
[Issue 14127] New: @trusted functions in std.array present unsafe interfaces
https://issues.dlang.org/show_bug.cgi?id=14127
Issue ID: 14127
Summary: @trusted functions in std.array present unsafe
interfaces
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Functions marked as @trusted must present safe interfaces, or the code they are
used in cannot be trusted. std.array has several of these:
Line 100:
static auto trustedAllocateArray(size_t n) @trusted nothrow
{
return uninitializedArray!(Unqual!E[])(n);
}
returning uninitialized data is not safe.
Line 482:
auto uninitializedArray(T, I...)(I sizes) nothrow @trusted
returning uninitialized pointers is unsafe.
Line 868:
void trustedMemmove(void* d, const void* s, size_t len) @trusted
{
memmove(d, s, len);
}
declaring something as trusted doth not make it trustable.
Line 899:
static auto trustedAllocateArray(size_t n) @trusted nothrow
{
return uninitializedArray!(T[])(n);
}
again with the uninitialized data.
Line 1606, 1664, 1706:
static U trustedCast(U, V)(V v) @trusted { return cast(U) v; }
trivial wrappers around unsafe operations does not make them safe.
Line 2640:
()@trusted{ _data.arr = _data.arr[0 .. _data.capacity]; }();
trivial wrappers around unsafe operations does not make them safe.
Line 2656:
auto bi = ()@trusted{ return
GC.qalloc(newlen * T.sizeof, blockAttribute!T);
}();
trivial wrappers around unsafe operations does not make them safe.
Line 2668:
if (len)
()@trusted{ memcpy(bi.base, _data.arr.ptr, len * T.sizeof); }();
_data.arr = ()@trusted{ return (cast(Unqual!T*)bi.base)[0 .. len]; }();
trivial wrappers around unsafe operations does not make them safe.
Line 2723:
auto bigDataFun() @trusted nothrow { return _data.arr.ptr[0 .. len + 1];}
trivial wrappers around unsafe operations does not make them safe.
Line 2729:
auto ref uitem() @trusted nothrow @property { return cast(Unqual!T)item; }
trivial wrappers around unsafe operations does not make them safe.
Line 2773:
auto bigDataFun() @trusted nothrow { return _data.arr.ptr[0 .. newlen];}
trivial wrappers around unsafe operations does not make them safe.
Line 2839:
void clear() @safe pure nothrow
{
if (_data)
{
_data.arr = ()@trusted{ return _data.arr.ptr[0 .. 0]; }();
}
}
clear() is @trusted, it is not @safe.
Line 2857:
enforce(newlength = _data.arr.length);
_data.arr = ()@trusted{ return _data.arr.ptr[0 .. newlength]; }();
The enforcement must go inside the @trusted code, not outside.
--
[Issue 14127] @trusted functions in std.array present unsafe interfaces
https://issues.dlang.org/show_bug.cgi?id=14127 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- I actually added some @trusted lambdas to enclose unsafe operations to make Appender usable in @safe code. But at least they would not do actual unsafe behavior because Appender manages memory pointer and its valid size. --
[Issue 9808] with statement does not work with opDispatch
https://issues.dlang.org/show_bug.cgi?id=9808 Alex Parrill initrd...@gmail.com changed: What|Removed |Added CC||initrd...@gmail.com --- Comment #1 from Alex Parrill initrd...@gmail.com --- This still happens in DMD 2.066.1 under Windows 7. It'd be nice to have this fixed, or otherwise resolved at least. See http://forum.dlang.org/thread/djxelqtyjyabrvzmt...@forum.dlang.org for another test case, as well as a hack-y workaround. --
[Issue 14112] Phobos git master doesn't build with MSVC-built compiler (DIP25)
https://issues.dlang.org/show_bug.cgi?id=14112 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- I tried it and it works with the DMC build DMD. Looks like the VS C++ compiler has a bug in it! Does VS have any valgrind-like feature you can try? --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- Sounds from the comments that this bug is invalid. --
