https://issues.dlang.org/show_bug.cgi?id=17928
--- Comment #7 from anonymous4 ---
(In reply to Carsten Blüggel from comment #5)
> I submitted PR https://github.com/dlang/dlang.org/pull/2126
It only applies to @safe code and dip1000 as a fix to safety checks, @system
still has old behavior as it's
https://issues.dlang.org/show_bug.cgi?id=8295
--- Comment #9 from anonymous4 ---
It might own the struct, but not the referenced data. Again example is
reference counter: destruction can depend on sharing. Another example is that
shared data can't be (de)allocated with thread local allocator.
--
https://issues.dlang.org/show_bug.cgi?id=7721
Simen Kjaeraas changed:
What|Removed |Added
Summary|Loss of template context|Nested template loses
|whe
https://issues.dlang.org/show_bug.cgi?id=18432
Issue ID: 18432
Summary: alias x = x where x is an imported symbol should
result in an error
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status:
https://issues.dlang.org/show_bug.cgi?id=18430
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from Razv
https://issues.dlang.org/show_bug.cgi?id=18403
ag0ae...@gmail.com changed:
What|Removed |Added
CC||do.m...@foxmail.com
--- Comment #4 from
https://issues.dlang.org/show_bug.cgi?id=18431
ag0ae...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=18432
--- Comment #1 from RazvanN ---
Actually,
import std.stdio : writeln;
alias writeln = std.stdio.writeln;
Does not compile successfully, it issues an error : "Undefined identifier
std.stdio.writeln".
--
https://issues.dlang.org/show_bug.cgi?id=18427
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from Razv
https://issues.dlang.org/show_bug.cgi?id=18430
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/1701bf9f7ff68538ca4ae279078233e74bc3b617
Fix Issue 18430 - isSame is wrong for non global lambdas
http
https://issues.dlang.org/show_bug.cgi?id=18430
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://issues.dlang.org/show_bug.cgi?id=18429
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from Razv
https://issues.dlang.org/show_bug.cgi?id=18384
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://issues.dlang.org/show_bug.cgi?id=18384
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/06e40304b21a29420b40c3f2b8d4edeeaf96aa1f
Fix Issue 18384 - std.net.isemail is slow to import due
https://issues.dlang.org/show_bug.cgi?id=18433
Jonathan Marler changed:
What|Removed |Added
Hardware|x86 |All
OS|Windows
https://issues.dlang.org/show_bug.cgi?id=18433
Issue ID: 18433
Summary: rdmd ignores DFLAGS
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
https://issues.dlang.org/show_bug.cgi?id=15086
Jonathan Marler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #8 from Andrei Alexandrescu ---
I think at the least we can do a vastly better job at issuing error messages.
Per the discussion in :
===
This error occurs becase the module foo/bar.d is being loaded twice with 2
different names. The fir
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #9 from Andrei Alexandrescu ---
Meant to write:
Per the discussion in https://github.com/dlang/dmd/pull/7778
--
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #10 from Jonathan Marler ---
> I think at the least we can do a vastly better job at issuing error messages.
I'm limiting focus to this issue alone. Do you have an idea on a way to improve
the error message for this case?
CURRENT BEHAVI
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #11 from Andrei Alexandrescu ---
(In reply to Jonathan Marler from comment #10)
> > I think at the least we can do a vastly better job at issuing error
> > messages.
>
> I'm limiting focus to this issue alone. Do you have an idea on a w
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #12 from Andrei Alexandrescu ---
Also enclosing the file name in double quotes might be nice.
--
https://issues.dlang.org/show_bug.cgi?id=18434
Issue ID: 18434
Summary: Failing case of BigInt gcd
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Co
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #13 from Timothee Cour ---
I don't see what's controversial about the fact that this is broken and breaks
the module system.
Hopefully this other example will convince you, where all I do is change the
order of imports and goes from CT e
https://issues.dlang.org/show_bug.cgi?id=18434
hst...@quickfur.ath.cx changed:
What|Removed |Added
Keywords||pull
--- Comment #1 from hst...@quic
https://issues.dlang.org/show_bug.cgi?id=18434
hst...@quickfur.ath.cx changed:
What|Removed |Added
Summary|Failing case of BigInt gcd |BigInt gcd asserts when one
https://issues.dlang.org/show_bug.cgi?id=15086
ag0ae...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #15 from Timothee Cour ---
the example I just posted breaks this spec:
> The order in which ImportDeclarations occur has no significance.
--
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #16 from Andrei Alexandrescu ---
The example in which the order of imports makes or breaks the build is
compelling. Even better would be a bug whereby the project builds both ways but
does different things. That would be the smoking gun.
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #17 from Jonathan Marler ---
I was able to reproduce Timothee's example. The error only occurs if the
modules are specified in a particular order.
I also tested this using PR
(https://github.com/dlang/dmd/pull/7878#issuecomment-36536482
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #18 from Timothee Cour ---
> Even better would be a bug whereby the project builds both ways but does
> different things. That would be the smoking gun.
could shorten but this shows it:
./asdf/wrong.d
pragma(msg, __FILE__," ",__MODULE_
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #19 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #16)
> The example in which the order of imports makes or breaks the build is
> compelling. Even better would be a bug whereby the project builds both ways
> but
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #20 from Jonathan Marler ---
Confirmed ag0aep6g's example. Also confirmed the proposed PR treats the
example as an error.
version=A
foo.d(3): Deprecation: module `bar` from file baz.d must be imported with
'import bar;'
version=B
foo
https://issues.dlang.org/show_bug.cgi?id=18435
Issue ID: 18435
Summary: Use StatsCollector in shared environment
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Prior
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #21 from Walter Bright ---
(In reply to ag0aep6g from comment #19)
Thank you for providing a simple and clear test case to illustrate the issue.
It is indeed a problem that the order of imports is mattering, as this breaks a
fundamental
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #22 from Timothee Cour ---
I don't understand why the current behavior is desired.
Is there any single use case that can't be achieved without existing option
such as -mv?
-mv== use as source file for
--
https://issues.dlang.org/show_bug.cgi?id=18436
Issue ID: 18436
Summary: broken opCast fails silently when used with
std.conv.to
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Se
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #23 from Jonathan Marler ---
> I have not thought about this thoroughly, but I suspect the core of a fix can
> be along the lines of detecting that an explicit import of bar.d is done
> using two different names in the same module.
I t
https://issues.dlang.org/show_bug.cgi?id=15086
--- Comment #24 from Jonathan Marler ---
> I have not thought about this thoroughly, but I suspect the core of a fix can
> be along the lines of detecting that an explicit import of bar.d is done
> using two different names in the same module.
Aft
https://issues.dlang.org/show_bug.cgi?id=9978
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #4 from Martin Nowak
40 matches
Mail list logo