[Issue 17194] [scope] Fwd reference error with nested struct
https://issues.dlang.org/show_bug.cgi?id=17194 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright --- This is a bit of a hopeless circular tangle. 'scope' is ignored if the type has no pointers. So S is checked for pointers. S.a is of type S2, which then must be checked for pointers. Checking S2 for pointers means evaluating each member to see if it is a field, which gets us back to looking at the 'scope'. Not sure if this is reasonably fixable. --
[Issue 17796] New: ldc's -oq (write full module path for objects) breaks linking
https://issues.dlang.org/show_bug.cgi?id=17796 Issue ID: 17796 Summary: ldc's -oq (write full module path for objects) breaks linking Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: blocker Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: iamthewilsona...@hotmail.com ldc's `-oq` flag to enable writing the fully qualified module name as the name for the .obj confuses visuald. It tells the linker to look for `\build\path\mod.obj` instead of `\build\path\fully.qualified.name.mod.obj`. for a module with declaration `module fully.qualified.name.mod;`. This prevents any projects that require `-oq` (due to their module layout) from linking with visual studio / visuald. One can still use dub (which just calls the compiler directly, it knows what its doing) manually on the command line to successfully build and link. --
[Issue 17684] [REG 2.062] `static alias this` bug or incomplete implementation?
https://issues.dlang.org/show_bug.cgi?id=17684 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/bc8d7d8b2419dcd7cb43e2ab819896fd79bb2fc0 Fix Issue 17684 - [REG 2.062] static alias this (Part 3) https://github.com/dlang/dmd/commit/c179e9c4d769506fe6cd6acd412bd5583badfb3f Merge pull request #7106 from JinShil/static_alias_this_3 Fix Issue 17684 - [REG 2.062] static alias this (Part 3) --
[Issue 17795] [scope] Scope errors not detected in ~= operation
https://issues.dlang.org/show_bug.cgi?id=17795 Walter Bright changed: What|Removed |Added Keywords||safe --
[Issue 17795] New: [scope] Scope errors not detected in ~= operation
https://issues.dlang.org/show_bug.cgi?id=17795
Issue ID: 17795
Summary: [scope] Scope errors not detected in ~= operation
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
As reported by Mathias Lang:
// Compiles with -dip1000, but should not
void main () @safe
{
int* ptr = bar();
assert(ptr !is null);
}
int* bar () @safe
{
int i;
int*[][] arr = new int*[][](1);
arr[0] ~= &i;
return arr[0][0];
}
--
[Issue 15492] ICE (segfault) on class { auto f() with out contract }
https://issues.dlang.org/show_bug.cgi?id=15492 Simon Na. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Simon Na. --- With dmd v2.075.1, the source example from 2016-01-01 builds and links without errors, on both Windows and 64-bit Arch. Closing this issue as worksforme. --
[Issue 8494] Return value for Tuple.opAssign
https://issues.dlang.org/show_bug.cgi?id=8494 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #8 from Simen Kjaeraas --- As has been pointed out, part of this bug is a two-line fix in typecons.d to have opAssign return ref Tuple. (PR: https://github.com/dlang/phobos/pull/5713) The other part is bigger - we're looking at either multiple alias this or implicitly casting AliasSeq!(3) to int. I'd argue the latter is probably the best solution here. At any rate, that's a DMD fix, not Phobos. --
[Issue 17794] New: Interactive tutorial is not accessible to blind programmers
https://issues.dlang.org/show_bug.cgi?id=17794 Issue ID: 17794 Summary: Interactive tutorial is not accessible to blind programmers Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com jareds was kind enough to do a quick evaluation of dlang.org's accessibility to blind programmers. Here is his report: "The site appears to generally be accessible with the exception of the interactive tutorial. I'm not a web accessibility expert so don't know the details. There are two major issues. The biggest one is my inability to arrow through the code in an edit field. I can read the text outside of the edit field, but it's difficult since line numbers are interspersed with the text. My assumption is that your using an open source editor which is inaccessible, but I have not had the time to look at the tutorial on Github. The second issue is that there are buttons that my screen reader reads as "button". While run, edit, and format are read properly several other buttons are not." --
[Issue 8494] Return value for Tuple.opAssign
https://issues.dlang.org/show_bug.cgi?id=8494 --- Comment #7 from ZombineDev --- (In reply to RazvanN from comment #6) > > That is a great idea. Unfortunately, I am not very well versed with Slack, > so do you mind creating the channel? Done, you should have gotten an invitation. If you log in on Slack, you should see the channel somewhere on your left. --
[Issue 8494] Return value for Tuple.opAssign
https://issues.dlang.org/show_bug.cgi?id=8494 --- Comment #6 from RazvanN --- (In reply to ZombineDev from comment #5) > > Sorry for my misunderstanding, but closing a bug report which seems invalid > > is the most efficient way to bring it to the attention of everyone. > > No problem, the only issue is that people on the CC list are guaranteed to > be notified that the bug is closed. I saw this one only by chance. > On the other hand, we do need to triage bugs, so we need an efficient > solution for this. How about we setting up a bug-triage channel on Slack? That is a great idea. Unfortunately, I am not very well versed with Slack, so do you mind creating the channel? --
[Issue 8494] Return value for Tuple.opAssign
https://issues.dlang.org/show_bug.cgi?id=8494 --- Comment #5 from ZombineDev --- > Sorry for my misunderstanding, but closing a bug report which seems invalid > is the most efficient way to bring it to the attention of everyone. No problem, the only issue is that people on the CC list are guaranteed to be notified that the bug is closed. I saw this one only by chance. On the other hand, we do need to triage bugs, so we need an efficient solution for this. How about we setting up a bug-triage channel on Slack? --
[Issue 8882] map, filter, iota and zip in pure (and nothrow) functions
https://issues.dlang.org/show_bug.cgi?id=8882
--- Comment #10 from ZombineDev ---
(In reply to RazvanN from comment #9)
> (In reply to ZombineDev from comment #8)
> > While, the OP code compiles, zip is not yet nothrow. See:
> >
> > ```
> > import std.algorithm: map, filter;
> > import std.range: iota, zip, array;
> > import std.typecons : tuple;
> >
> > auto get() pure nothrow
> > {
> > auto m = map!q{a * a}([1, 2, 3]);
> > auto f = filter!q{ a > 1 }([1, 2, 3]);
> > auto i = iota(1, 10, 2);
> > auto z = zip([1, 2, 3], [10, 20, 30]);
> > return tuple(m.array, f.array, i.array, z.array);
> > }
> >
> > void main()
> > {
> > import std.stdio;
> > writeln(get());
> > }
> > ```
> >
> > test.d(11): Error: function std.array.array!(Zip!(int[], int[])).array is
> > not nothrow
> > test.d(4): Error: nothrow function test.get may throw
>
> There already is issue 11466 [1] which addresses problem, so I suggest we
> close this and fix that one.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=11466
I missed that one, so yes, we should close this one, thanks.
--
[Issue 8494] Return value for Tuple.opAssign
https://issues.dlang.org/show_bug.cgi?id=8494 --- Comment #4 from RazvanN --- (In reply to ZombineDev from comment #3) > You're misunderstanding the OP. The whole point of this enhancement request > is to make T and Tuple!T interchangeable. Changing the return type of `bar` > misses the point completely. Essentially what this OP is asking is: > 1. Tuple.opAssign should return `this` (the object being modified) > 2. Tuple!T should implicitly convert to T. > > This comes from a higher-level goal that type constructors should be > indistinguishable from built-in types - there should be nothing that > user-defined can't do, that a built-in type can. > > Razvan, please refrain from closing valid enhancement requests. 1-2 years > ago bearophile was one of the most active community members and many of his > ideas helped shape the language and the standard library. While some of his > enhancement request are a bit vague and not always clear, quite often there > are good ideas in there. In particular, a future proposal for built-in > tuples may greatly benefit from many of his litmus tests. Sorry for my misunderstanding, but closing a bug report which seems invalid is the most efficient way to bring it to the attention of everyone. --
[Issue 8882] map, filter, iota and zip in pure (and nothrow) functions
https://issues.dlang.org/show_bug.cgi?id=8882
RazvanN changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #9 from RazvanN ---
(In reply to ZombineDev from comment #8)
> While, the OP code compiles, zip is not yet nothrow. See:
>
> ```
> import std.algorithm: map, filter;
> import std.range: iota, zip, array;
> import std.typecons : tuple;
>
> auto get() pure nothrow
> {
> auto m = map!q{a * a}([1, 2, 3]);
> auto f = filter!q{ a > 1 }([1, 2, 3]);
> auto i = iota(1, 10, 2);
> auto z = zip([1, 2, 3], [10, 20, 30]);
> return tuple(m.array, f.array, i.array, z.array);
> }
>
> void main()
> {
> import std.stdio;
> writeln(get());
> }
> ```
>
> test.d(11): Error: function std.array.array!(Zip!(int[], int[])).array is
> not nothrow
> test.d(4): Error: nothrow function test.get may throw
There already is issue 11466 [1] which addresses problem, so I suggest we close
this and fix that one.
[1] https://issues.dlang.org/show_bug.cgi?id=11466
--
