[Issue 20319] cast causing illegal instruction (core dump) in compiler
https://issues.dlang.org/show_bug.cgi?id=20319 --- Comment #1 from Bartek Siudeja --- Perhaps this is related to https://issues.dlang.org/show_bug.cgi?id=20318 --
[Issue 20319] New: cast causing illegal instruction (core dump) in compiler
https://issues.dlang.org/show_bug.cgi?id=20319
Issue ID: 20319
Summary: cast causing illegal instruction (core dump) in
compiler
Product: D
Version: D2
Hardware: x86
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: siu...@gmail.com
test on run.dlang.io
no compiler arguments
all dmd versions
code:
```
void main()
{
auto data = cast(const char[5][]) "qwert";
}
```
output:
```
Up to 2.085.1: Success and no output
Since 2.086.1: Status -4 and no output
```
Nightly gives `output: Illegal instruction (core dumped)`.
--
[Issue 20261] CustomFloat.epsilon yields infinity
https://issues.dlang.org/show_bug.cgi?id=20261 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/phobos pull request #7238 "Fix Issue 20261 - CustomFloat.epsilon yields infinity" was merged into master: - 4e81fe0ce6f39ef76041c09f65839983079ad9d5 by Bernhard Seckinger: Fix Issue 20261 - CustomFloat.epsilon yields infinity https://github.com/dlang/phobos/pull/7238 --
[Issue 14478] isInputRange should allow ranges of non-copyable elements
https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #15 from Jonathan M Davis --- This issue has some similarities to issue #15413, but 15413 deals with ranges which are non-copyable, whereas this deals with ranges with elements which are non-copyable (though a range with non-copyable elements would also be non-copyable if the elements were contained directly in the range as occurs with some range types - e.g. std.range's only). --
[Issue 15413] Foreach over range with @disable this(this) doesn't work
https://issues.dlang.org/show_bug.cgi?id=15413 --- Comment #4 from Jonathan M Davis --- I would note that this issue has some similarities to issue #14478, but 14478 deals with elements which are non-copyable, whereas this deals with ranges which are non-copyable (though a range with non-copyable elements would also be non-copyable if the elements were contained directly in the range). --
[Issue 15413] Foreach over range with @disable this(this) doesn't work
https://issues.dlang.org/show_bug.cgi?id=15413 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m Severity|normal |enhancement --- Comment #3 from Jonathan M Davis --- foreach specifically copies the range that it's given. If it didn't, then iterating over a dynamic array would consume it. It does unfortunately mean that whether a range is consumed or not depends on whether it's a reference type, pseudo-reference type, or value type, but that's a general problem with copying ranges. Either way, changing how foreach worked would break a lot of code. So, in order for this to work, ranges which are non-copyable would have to be treated differently from other ranges when using foreach. However, considering that almost all range-based code copies ranges, I find it hard to believe that having a non-copyable range makes much sense. And if you specifically are looking for foreach to work, you should just be able to use opApply instead of making the object a range. --
[Issue 20318] New: Illegal instruction (core dumped)
https://issues.dlang.org/show_bug.cgi?id=20318
Issue ID: 20318
Summary: Illegal instruction (core dumped)
Product: D
Version: D2
Hardware: x86
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ap...@hotmail.com
test from: https://run.dlang.io
build with: -dip1008 -profile=gc
import std.stdio;
void main()
{
write(ubyte.max);
}
output: Illegal instruction (core dumped)
--
[Issue 11725] [AA] Cannot dup const AA
https://issues.dlang.org/show_bug.cgi?id=11725 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @quickfur created dlang/druntime pull request #2838 "Fix issue 11725: AA.dup should return mutable AA where possible." fixing this issue: - Fix issue 11725: AA.dup should return mutable AA where possible. Since the original AA has been duplicated, it should be safe to mutate the copy. No need to needlessly restrict the copy to be const too. https://github.com/dlang/druntime/pull/2838 --
[Issue 1550] D DLLs close standard input/output streams when unloading
https://issues.dlang.org/show_bug.cgi?id=1550 --- Comment #7 from Rainer Schuetze --- The pull request for the dmc runtime has been merged https://github.com/DigitalMars/dmc/pull/3 , but there has never been an update to the released snn.lib AFAICT. --
[Issue 11725] [AA] Cannot dup const AA
https://issues.dlang.org/show_bug.cgi?id=11725 --- Comment #1 from hst...@quickfur.ath.cx --- Still happens on git master (b70b154d716b681c242f7d5fb3a4cea9449d508d). --
[Issue 20316] array properties fail hasMember
https://issues.dlang.org/show_bug.cgi?id=20316 John Colvin changed: What|Removed |Added Severity|major |regression --- Comment #1 from John Colvin --- This is a regression introduced in 2.065, before which .length and .ptr were found. AFAICT .capacity never worked --
[Issue 20317] New: Checked std.format Error: `"Attempted to access an uninitialized payload."`
https://issues.dlang.org/show_bug.cgi?id=20317
Issue ID: 20317
Summary: Checked std.format Error: `"Attempted to access an
uninitialized payload."`
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: acehr...@yahoo.com
import std.stdio;
import std.string;
void main() {
auto lines = File("foo").byLine;
auto result = format!"%s"(lines);
}
The compilation fails with
/usr/include/dmd/phobos/std/typecons.d(6455): Error: `"Attempted to access an
uninitialized payload."`
[...]
--
[Issue 20265] [REG2.088] Spurious deprecation message with Nullable!bool and -unittest
https://issues.dlang.org/show_bug.cgi?id=20265 Bartek Siudeja changed: What|Removed |Added CC||siu...@gmail.com --- Comment #1 from Bartek Siudeja --- `pragma(msg, typeof(Nullable!int.init));` also causes this warning. So other phobos functions are problematic, like `std.json.parseJSON`. --
[Issue 809] Should be possible to convert lazy argument to delegate
https://issues.dlang.org/show_bug.cgi?id=809 --- Comment #12 from Dlang Bot --- dlang/dlang.org pull request #2686 "Spec change for Issue 809" was merged into master: - c9fdeeca8e2c26a180c9db2b136864ba4ee9e576 by Razvan Nitu: Spec change for Issue 809 Merge after dmd PR: https://github.com/dlang/dmd/pull/10264 https://github.com/dlang/dlang.org/pull/2686 --
[Issue 20316] New: array properties fail hasMember
https://issues.dlang.org/show_bug.cgi?id=20316 Issue ID: 20316 Summary: array properties fail hasMember Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com pragma(msg, __traits(hasMember, int[], "length")); // false pragma(msg, __traits(hasMember, int[], "ptr")); // false pragma(msg, __traits(hasMember, int[], "capacity")); // false pragma(msg, __traits(hasMember, int[], "sizeof")); // true pragma(msg, __traits(hasMember, int[], "alignof")); // true --
[Issue 19878] Some NaNs are printed as -nan
https://issues.dlang.org/show_bug.cgi?id=19878 berni44 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #5 from berni44 --- According to the discussion of PR 7222, this is not considered a bug. --
[Issue 20315] checkaction=context fails for const(void[]) argument
https://issues.dlang.org/show_bug.cgi?id=20315 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @MoonlightSentinel created dlang/druntime pull request #2837 "Fix Issue 20315 - checkaction=context fails for const(void[]) argument" fixing this issue: - Fix Issue 20315 - checkaction=context fails for const(void[]) argument https://github.com/dlang/druntime/pull/2837 --
[Issue 20315] checkaction=context fails for const(void[]) argument
https://issues.dlang.org/show_bug.cgi?id=20315 --- Comment #1 from moonlightsenti...@disroot.org --- *Wrong braces: const(void[]) == typeof(typeid(X).initializer). --
[Issue 20315] New: checkaction=context fails for const(void[]) argument
https://issues.dlang.org/show_bug.cgi?id=20315
Issue ID: 20315
Summary: checkaction=context fails for const(void[]) argument
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: moonlightsenti...@disroot.org
The following unittest from object.d fails to compile with -unittest
-checkaction=context:
@safe unittest
{
// Bugzilla 14401
static class X
{
int a;
}
assert(typeid(X).initializer is typeid(X).m_init);
}
src/core/internal/dassert.d(110): Error: cannot implicitly convert expression
`idup(s)` of type `immutable(void)[]` to `string`
src/core/internal/dassert.d(209): Error: template instance
`core.internal.dassert.miniFormat!(const(void)[])` error instantiating
src/core/internal/dassert.d(17):instantiated from here:
`miniFormatFakeAttributes!(const(void)[])`
src/object.d(1117):instantiated from here: `_d_assert_fail!("is",
const(void)[], const(void)[])`
The is caused by miniFormat using string concenation when instantiated with
const(void[] == typeof(typeid(X).initializer)).
--
[Issue 20314] passing const variables to `only` forces const range element type
https://issues.dlang.org/show_bug.cgi?id=20314 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @FeepingCreature created dlang/phobos pull request #7253 "Fix issue 20314: pass `only` parameters by value" fixing this issue: - Fix issue 20314: pass `only` parameters by value https://github.com/dlang/phobos/pull/7253 --
[Issue 3755] Forward declaration templates something (D1 only)
https://issues.dlang.org/show_bug.cgi?id=3755 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from RazvanN --- Closing as D1 is no longer supported. --
[Issue 3678] (D1 only) Should disallow throwing of exceptions that are not derived from Exception
https://issues.dlang.org/show_bug.cgi?id=3678 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --
[Issue 20314] New: passing const variables to `only` forces const range element type
https://issues.dlang.org/show_bug.cgi?id=20314
Issue ID: 20314
Summary: passing const variables to `only` forces const range
element type
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Consider this code:
import std;
void main()
{
const string s = "foo", t = "bar";
auto range = only(s, t);
[range].joiner(only(", ")).join.writeln;
}
Since `only` takes its parameters by `auto ref`, the fact that s and t are
`const string` forces `only` to have an `ElementType` of `const(string)`, which
then breaks `joiner`.
There's no reason for `only` to be `auto ref`, since it copies its parameters
anyways.
--
[Issue 3603] Allow selective import syntax to import several modules from a package
https://issues.dlang.org/show_bug.cgi?id=3603
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #7 from RazvanN ---
(In reply to Leandro Lucarella from comment #0)
> Importing a lot of stuff from a deeply nested modules is very annoying
> because it needs a lot of repeating, for example:
>
> import really.very.deeply.nested.package.module1;
> import really.very.deeply.nested.package.module2;
> import really.very.deeply.nested.package.module3;
>
> Allowing selective import syntax to do this in a more concise way would be a
> great improvement over this, the above example could be rewritten as:
>
> import really.very.deeply.nested.package: module1, module2, module3;
>
> Maybe this should be semantically equivalent to this instead of the first
> example:
>
> import module1 = really.very.deeply.nested.package;
> import module2 = really.very.deeply.nested.package;
> import module3 = really.very.deeply.nested.package;
>
> It can be a little more consistent with selective imports. But we still have
> to same problem if we don't want to type module1.symbol and want to type
> just symbol instead.
>
> Maybe a new syntax can be introduced to allow that, like:
> import really.very.deeply.nested.package { module1, module2, module3 };
>
> Or something similar.
This can be trivially solved by:
import really;
Closing as INVALID
--
[Issue 3614] empty tuples not assignable: Error: tuple has no effect in expression (tuple())
https://issues.dlang.org/show_bug.cgi?id=3614 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #1 from RazvanN --- This has been fixed in D2 and D1 is no longer supported. Closing as fixed. --
[Issue 3632] modify float is float to do a bitwise compare
https://issues.dlang.org/show_bug.cgi?id=3632 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #36 from RazvanN --- Fixed by: https://github.com/dlang/dmd/pull/9897 --
[Issue 1547] Default parameter values should use implicit static opCall
https://issues.dlang.org/show_bug.cgi?id=1547 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #4 from Nick Treleaven --- (In reply to Bill Baxter from comment #0) > void foo(Struct s = null) Nice that this is now allowed, is it possible to also allow calling foo(null)? Then structs could be a drop-in replacement for pointers, but doing some extra checks on certain operations. --
[Issue 20313] Inconsistent behavior of wouldHaveBlocked on Windows
https://issues.dlang.org/show_bug.cgi?id=20313 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @adamdruppe updated dlang/phobos pull request #7250 "handle timeout on Windows the same as on Linux - no other way in curr…" fixing this issue: - Fix Issue 20313 - test timeout error condition https://github.com/dlang/phobos/pull/7250 --
[Issue 20313] New: Inconsistent behavior of wouldHaveBlocked on Windows
https://issues.dlang.org/show_bug.cgi?id=20313 Issue ID: 20313 Summary: Inconsistent behavior of wouldHaveBlocked on Windows Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: destructiona...@gmail.com On Linux, socket timeouts trigger wouldHaveBlocked but on Windows it does not, and none of the std.socket functions offer a way to check that error code. --
[Issue 1974] overloaded assignment operators work on non-lvalues
https://issues.dlang.org/show_bug.cgi?id=1974 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from RazvanN --- Closing on the basis of: https://forum.dlang.org/post/hyacdnjwraldlnmdl...@forum.dlang.org --
[Issue 1760] Closures - Variable unnecessarily allocated on heap
https://issues.dlang.org/show_bug.cgi?id=1760 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #7 from RazvanN --- Closing as WONTFIX on the basis of: https://github.com/dlang/dmd/pull/10442 --
[Issue 20312] Multiple inheritance covariance breaks vtable dispatch
https://issues.dlang.org/show_bug.cgi?id=20312 Radu Racariu changed: What|Removed |Added CC||radu.raca...@gmail.com Hardware|x86_64 |All OS|Linux |All Severity|normal |major --
[Issue 2159] Confusion between function call and C++ style function address
https://issues.dlang.org/show_bug.cgi?id=2159 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 1448] UTF-8 output to console is seriously broken
https://issues.dlang.org/show_bug.cgi?id=1448 --- Comment #19 from RazvanN --- (In reply to kinke from comment #18) > This isn't solved, but would now be solvable with recent Windows versions. > > There are 2 things about this: > * DMD outputs a mix of UTF-8 and strings in the current codepage, AFAIK > without setting any console codepage, so DMD output on Windows can be > garbage. LDC v1.17 fixes this for LDC. How does LDC solve the problem? > * User programs writing UTF-8 strings to the console suffer from the same > issue. This *could* be worked around by setting the console codepage in > druntime's _d_run_main and resetting it to the original one before > termination. --
[Issue 1550] D DLLs close standard input/output streams when unloading
https://issues.dlang.org/show_bug.cgi?id=1550 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #6 from RazvanN --- Does this issue still manifests? --
[Issue 1551] 80kb memory leak with DLLs
https://issues.dlang.org/show_bug.cgi?id=1551 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |REMIND --- Comment #2 from RazvanN --- This issue is marked as D1. Closing as D1 is no longer supported. If this issue manifests in D2 please reopen. --
[Issue 2660] Change #line to pragma(line)
https://issues.dlang.org/show_bug.cgi?id=2660 Richard Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |WONTFIX --- Comment #16 from Richard Cattermole --- This is part of the specification as a special token sequence. https://dlang.org/spec/lex.html#special-token-sequence If this was to be changed today it would require a DIP. I am closing it for this reason and marking it WONTFIX given that it was created before the DIP process. --
[Issue 2660] Change #line to pragma(line)
https://issues.dlang.org/show_bug.cgi?id=2660 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #15 from RazvanN --- Should we close this? --
[Issue 1596] op*Assign should return void
https://issues.dlang.org/show_bug.cgi?id=1596 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #12 from RazvanN --- I'm going to close this since changing op*Assign to make it mandatory to return a specific type would break a lot of code. --
