[Issue 3420] Allow string import of files using subdirectories

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3420

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #20 from Vladimir Panteleev  ---
This was fixed for POSIX in 2.041 and for Windows in 2.072.0.

--

[Issue 17744] Type system hole: returning inout delegates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17744

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

[Issue 17743] Type system hole: escaping inout delegates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17743

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

[Issue 17736] bigint opunary should be better performing

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17736

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17746

--

[Issue 17746] Improve BigInt memory usage

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17746

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17736

--

[Issue 17736] bigint opunary should be better performing

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17736

--- Comment #5 from hst...@quickfur.ath.cx ---
Wrote it up here:

https://issues.dlang.org/show_bug.cgi?id=17746

Doesn't necessarily mean I have the time to actually implement this, though.
:-)

--

[Issue 17746] New: Improve BigInt memory usage

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17746

  Issue ID: 17746
   Summary: Improve BigInt memory usage
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Currently, operations on BigInt always allocates a new BigInt instance to hold
the result, even if it is valid and possible to reuse the space of (one of) its
operand(s).  For example, `BigInt x=...; x++;` will always allocate a new
BigInt in the course of evaluating `x++`, even though it could have more
efficiently updated x in-place.

As far as I can tell, the reason BigInt operations are implemented this way is
because it was intended to be a drop-in replacement for fixed-width ints, and
so it must replicate equivalent semantics, in particular by-value semantics.
Since BigInt.opAssign only copies by reference (probably for efficiency
reasons, since otherwise passing BigInt between functions could entail
expensive copying), the only way to ensure by-value semantics is to never
modify an existing BigInt instance, but always allocate a new instance for
holding the result of operations.

The current implementation has the following drawbacks:

- Excessive allocations: every operation on a BigInt involves an allocation,
including trivial operations like ++, that only rarely actually requires
allocating a new BigInt (i.e., only once every 2^n calls to opUnary!"++", where
n is the current size of the BigInt).  This increases GC pressure in BigInt
code unnecessarily.

- Suboptimal performance when the result of an operation fits within one of its
operations and said operand is not aliased. `x++`, for example, entails
allocating a new BigInt and copying the contents of x over, whereas updating
in-place would, most of the time, require updating only 1 word of BigInt data
or just a few words.


This enhancement request proposes the following change to BigInt's
implementation:

1) Add a reference counting scheme to BigInt. Since BigInt is already a wrapper
around what's essentially a reference to the actual data, this would not be a
huge change.

2) Implement in-place versions of the current BigInt operations, where
possible. (Certain operations like * may not make sense as an in-place
algorithm, since allocation of temporary working space will be needed anyway.)

3) In BigInt's overloaded operators, whenever the current reference count is 1,
and an in-place algorithm is available, use the in-place algorithm to update
the BigInt in-place rather than allocate a new BigInt to hold the result.

In addition to better memory usage and better efficiency for trivial operations
like ++, the proposed change also opens up the possibility of making BigInt
usable in a @nogc context.

--

[Issue 17745] New: Upgrade DLang Bugzilla to 4.4.12

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17745

  Issue ID: 17745
   Summary: Upgrade DLang Bugzilla to 4.4.12
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: lpso...@netscape.net

issues.dlang.org is currently running Bugzilla 4.4.2. Many security
vulnerabilities have been fixed meanwhile:

  https://www.bugzilla.org/security/

Upgrading to 4.4.12 should be straightforward as it's the same branch.

--

[Issue 17738] access to local alias from outside compiles but execution hangs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17738

--- Comment #1 from Dominikus Dittes Scherkl  ---
Sorry, that was gdc, and it was the compilation that only stopped after stack
overflow was reached (which took about 10 minutes).

dmd (2.075.0) directly fails with a segmentation fault (exit code 139).

(and of course it fails only, if foo is actually instantiated somewhere)

So, is it not allowed to access (type)definitions from outside the function
where they are declared, or is this a real bug?

If it should not be allowed (which I would call a pitty), than a proper error
message should be provided. Else I would expect foo and foo2 to compile to
exactly the same assembly code.

--

[Issue 17744] New: Type system hole: returning inout delegates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17744

  Issue ID: 17744
   Summary: Type system hole: returning inout delegates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD v2.075.0:

@safe:
int a;
immutable(int) b=2;

inout(int)* delegate(inout(int)*)@safe delegate()@safe foo(inout(int)* y){
inout(int)* bar(inout(int)* p){
return y;
}
return ()=>
}
void main(){
int* y=foo()()();
*y=3;
assert( is y); // passes. ouch.
assert(b is *); // fails!
}

If  is returned directly instead of ()=>, DMD applies a strange
work-around (it replaces `inout` in the returned delegate by `const`).

--

[Issue 17743] New: Type system hole: escaping inout delegates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17743

  Issue ID: 17743
   Summary: Type system hole: escaping inout delegates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD v.2075.0:

@safe:
int a;
immutable(int) b=2;

inout(int)* delegate(inout(int)*) dg;
inout(int)* prepare(inout(int)* x){
dg = y=>x;
return x;
}
void main(){
prepare();
int* y=dg();
assert( is y); // passes. ouch.
*y=3;
assert(b is *); // fails!
}

--

[Issue 14916] opDispatch: no property error for parameter type mismatch

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14916

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--

[Issue 8006] Implement proper in-place-modification for properties

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8006

--- Comment #6 from Mike  ---
An attempt at a partial implementation:
https://github.com/dlang/dmd/pull/7079/files

--