[Issue 18874] New: Add thatneedle.com to organizations using D
https://issues.dlang.org/show_bug.cgi?id=18874 Issue ID: 18874 Summary: Add thatneedle.com to organizations using D Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: m...@thatneedle.com http://thatneedle.com is focused on Natural Language Processing and information retrieval/search. Thatneedle.com uses D for data processing, and rapid prototyping. Please keep up the great work. --
[Issue 18874] Add thatneedle.com to organizations using D
https://issues.dlang.org/show_bug.cgi?id=18874 m...@thatneedle.com changed: What|Removed |Added CC||m...@thatneedle.com --
[Issue 15475] Ddoc code sample with unbalanced paren comes out as macro
https://issues.dlang.org/show_bug.cgi?id=15475 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/e0e23b7250401521c8db05c079ae2b59408afb0e Fix Issue 15475 - Fix more cases https://github.com/dlang/dmd/commit/843dbf3fa056a0a35b5c59c58a129ec65818b24d Merge pull request #8238 from dgileadi/ddoc-unbalanced-parens-in-code Fix more cases of bug 15475 --
[Issue 15475] Ddoc code sample with unbalanced paren comes out as macro
https://issues.dlang.org/show_bug.cgi?id=15475 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18875] New: String literals can't disambiguate between const(char)[] and const(char)* overload.
https://issues.dlang.org/show_bug.cgi?id=18875
Issue ID: 18875
Summary: String literals can't disambiguate between
const(char)[] and const(char)* overload.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dmitry.o...@gmail.com
void add(const(char)* path){ }
void add(const(char)[] path){ }
void main(){
add("ABC");
}
On DMD 2.080 prints:
bug.d(6): Error: bug.add called with argument types (string) matches both:
bug.d(1): bug.add(const(char)* path)
and:
bug.d(3): bug.add(const(char)[] path)
I believe that for string literals we should probably pick D version of
const(char)[]. Some might argue the other way around since it's likely a
C-string function so it will be more efficient to present it as C-string.
Truth be told we need a sentinel terminated string type in DRuntime and cstring
would be one of them.
At the very least there has to be something in the spec about this.
--
[Issue 18415] Typedef ignores @disabled default constructor
https://issues.dlang.org/show_bug.cgi?id=18415 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/2cd3b5dac201c4168e242adfe94996fd67050f53 fix issue 18415 - Typedef ignores `@disabled` default constructor https://github.com/dlang/phobos/commit/b62baca794d34e37e113ef332c95c35f76f347af Merge pull request #6514 from BBasile/issue-18415 fix issue 18415 - Typedef ignores `@disabled` default constructor merged-on-behalf-of: MetaLang --
[Issue 18876] New: Contradiction in Spec Concerning Properties
https://issues.dlang.org/show_bug.cgi?id=18876 Issue ID: 18876 Summary: Contradiction in Spec Concerning Properties Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: qs.il.paperi...@gmail.com In section "Property Functions"[1] of "Functions" page, it says on 2., second point: "@property functions can only have zero, one or two parameters." and on 8.: "If a property function has no parameters, it works as a getter. If has exactly one parameter, it works as a setter." These cannot be understood simultaneously. 8. implies a @property must have one or no parameters. [1] https://dlang.org/spec/function.html#property-functions --
[Issue 13741] std.traits.moduleName & packageName do not work with functions that have parameters
https://issues.dlang.org/show_bug.cgi?id=13741 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/593a4e2e39312daef00023f924a0c45af1cf082c fix issue 13741 - std.traits.moduleName does not work with functions that have parameters https://github.com/dlang/phobos/commit/09816a2e8b960e2f49bcbd2da754136bdd6501b8 Merge pull request #6494 from BBasile/issue-13741 fix issue 13741 - std.traits.moduleName does not work with functions that have parameters merged-on-behalf-of: MetaLang --
[Issue 13741] std.traits.moduleName & packageName do not work with functions that have parameters
https://issues.dlang.org/show_bug.cgi?id=13741 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18877] New: std.allocator: RCIAllocator's .alignment() method is not readable at compile-time
https://issues.dlang.org/show_bug.cgi?id=18877 Issue ID: 18877 Summary: std.allocator: RCIAllocator's .alignment() method is not readable at compile-time Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: phobos Assignee: nob...@puremagic.com Reporter: dlang-bugzi...@thecybershadow.net Created attachment 1696 --> https://issues.dlang.org/attachment.cgi?id=1696&action=edit Draft patch for making alignment a method Many building block allocators have a line such as: enum uint alignment = Allocator.alignment; or: alias alignment = ParentAllocator.alignment; This doesn't work when the parent allocator is an opaque class. Possible solutions: - Forego use of alignment as a compile-time value, instead treating it as a runtime value everywhere. Rely on compiler optimizations to punch through the layers as needed. This is probably not feasible as many allocators rely on the underlying types having a predefined, constant alignment. Using ParentAllocator.init.alignment allows hacking around this, though. Attached is a draft patch towards this approach. - Declare alignment as an enum/alias iff ParentAllocator's alignment can be read at compile-time. For allocators that require knowing the alignment beforehand, this can be made as an explicit check (to produce a human-readable error message if they are used with e.g. RCIAllocator). --
[Issue 18796] std.algorithm.substitute asserts on empty range
https://issues.dlang.org/show_bug.cgi?id=18796 Andrei Vasile changed: What|Removed |Added CC||andrei.vasil...@gmail.com Assignee|nob...@puremagic.com|andrei.vasil...@gmail.com --
[Issue 18878] New: Short-circuiting && not behaving correctly
https://issues.dlang.org/show_bug.cgi?id=18878 Issue ID: 18878 Summary: Short-circuiting && not behaving correctly Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Well, this is not okay! enum isInternal(string field) = field.length >= 2 && field[0..2] == "__"; pragma(msg, isInternal!"x"); > error : string slice `[0 .. 2]` is out of bounds My code used to compile. --
[Issue 18879] New: !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 Issue ID: 18879 Summary: !is doesn't highlight correctly Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com `in` and `is()` are highlighted as keywords, but `!in` and `!is()` are not highlighted correctly. --
[Issue 18879] !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 Manu changed: What|Removed |Added Assignee|nob...@puremagic.com|r.sagita...@gmx.de --
[Issue 18879] !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 --- Comment #1 from Rainer Schuetze --- `in` and `is` can be both operators or keywords depending on context, so different colors are expected. A preceding `!` is a separate token, i.e. there can be arbitrary spaces and comments in between. This makes it pretty difficult for the lexer to highlight these correctly, but there is actually support for that by asking the parser. It seems this is broken, though. --
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- I've implemented this, but allow disabling it with an option on the Debugger->Mago page. You can try it in https://ci.appveyor.com/project/rainers/visuald/build/job/sd42f639wlwh77qc/artifacts It doesn't show symbol names, though, just raw pointer values. I'm not sure that's good enough. --
[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line
https://issues.dlang.org/show_bug.cgi?id=18880 johanenge...@weka.io changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All Severity|enhancement |regression --
[Issue 18880] New: [REG2.079] Miscompilation of unittests when two are mixed-in on one line
https://issues.dlang.org/show_bug.cgi?id=18880
Issue ID: 18880
Summary: [REG2.079] Miscompilation of unittests when two are
mixed-in on one line
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
With the change to deterministic unittest function naming, this bug was
introduced:
When N unittests are mixed-in on the same line, the first one is run N times.
Testcase:
```
mixin(genTest("666")); mixin(genTest("777"));
int i;
string genTest(string a)
{
return "unittest { i += " ~ a ~ "; }";
}
void main()
{
// All unittests have been when we reach here.
assert(i == 0 + 666 + 777);
// Since 2.079 this passes!
// assert(i == 0 + 666 + 666);
}
```
fails with:
dmd -unittest -run testcase.d
since 2.079.
It's caused by the naming of the unittest functions. The source location of the
unittest is used in the name, but the source location inside mixins behaves
strange: inside the mixin the linenumbers are offset with the line number of
the mixin statement, but the column of the mixin statement is not reflected in
Locs inside a mixin (only in the filename of the Loc).
Thus only one function is made "...__unittest_L1_C1FZv" and it is called twice.
(the second unittest gets the same name and is subsequently not codegenned
because the symbol is already defined)
--
[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line
https://issues.dlang.org/show_bug.cgi?id=18880 --- Comment #1 from johanenge...@weka.io --- Related issue discussing the mixin linecount problem: https://issues.dlang.org/show_bug.cgi?id=2887 --
[Issue 18879] !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 --- Comment #2 from Manu --- I think they should both be highlighted when used both as operators and as keywords... so I don't think that distinction of case matters? --
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 --- Comment #2 from Manu --- Right, I've noticed that our pointers don't seem to show symbol names like C++ does... why is that? Is that possible to fix? The experience should match C++. --
[Issue 18880] [REG2.079] Miscompilation of unittests when two are mixed-in on one line
https://issues.dlang.org/show_bug.cgi?id=18880
--- Comment #2 from johanenge...@weka.io ---
Things are worse:
```
static foreach(s; ["666", "777"]) {
mixin(genTest(s));
}
int i;
string genTest(string a)
{
return "unittest { i += " ~ a ~ "; }";
}
void main()
{
assert(i == 0 + 666 + 666);
}
```
Thus: the exact source location is not necessarily unique and so an extra
uniqueness factor is needed to generate the unittest function names. (note:
must still be deterministic across separate compilations!)
--
[Issue 18868] Separate compilation generates two static this functions, runs it twice
https://issues.dlang.org/show_bug.cgi?id=18868
--- Comment #2 from johanenge...@weka.io ---
Extra testcase that must be added and considered (currently works):
```
static foreach(s; ["666", "777"]) {
mixin(genCtor(s));
}
int i;
string genCtor(string a)
{
return "static this() { i += " ~ a ~ "; }";
}
void main()
{
assert(i == 0 + 666 + 777);
}
```
--
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 --- Comment #3 from Manu --- I just installed that build. I can see an item in place of the vtable: -tclass 0x02D2 Source.Base +[Source.Derived]0x02D2 Source.Derived object.Object D0006: Error: Type resolve failed x 10 int y 20 int It seems there's an object.Object item there, which fails to evaluate correctly. It should be void** (or rather, void*[N] to inspect properly) right? --
[Issue 18881] New: extern(C++) classes don't work properly in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18881
Issue ID: 18881
Summary: extern(C++) classes don't work properly in debuginfo
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: visuald
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
Here's a test class:
extern(C++) class BaseCPP
{
~this() {}
void poo() {}
int x = 10;
int y = 20;
}
extern(C++) class DerivedCPP : BaseCPP
{
int z;
}
void main()
{
DerivedCPP d = new DerivedCPP;
BaseCPP b = d;
int x = 10; // PLACE BREAKPOINT HERE
}
At the breakpoint, inspect the value of 'b'.
You should expect to see:
- b0x0073fb2c {z=0} BaseCPP* {DerivedCPP}
+[DerivedCPP] {z=0} DerivedCPP
+__vfptr 0x00394c50 {DerivedCPP.__vftable} void**
x 10 int
y 20 int
But instead, there is only the 2 members of BaseCPP: `x` and `y`.
extern(C++) classes are missing their type, entry to get from base-class
pointer to the most-derived type, and the vtable.
C++ populates the class with all this information, so extern(C++) classes
should be able to show the exact same set of members as when debugging in C++?
--
[Issue 18881] extern(C++) classes don't work properly in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18881 Manu changed: What|Removed |Added Assignee|nob...@puremagic.com|r.sagita...@gmx.de --
[Issue 18881] extern(C++) classes don't work properly in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18881 --- Comment #1 from Manu --- Sadly, more of my D code is extern(C++) than not >_< --
[Issue 18882] New: __gshared not displaying in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18882 Issue ID: 18882 Summary: __gshared not displaying in debuginfo Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com In DMD, put a breakpoint somewhere at the top of mars.d: tryMain() This function refers to `global` frequently, eg `global.params`, `global.inifilename`, etc. Notice that the debuginfo seems to be missing for `global`, the debugger just says "Symbol not found", and you can't inspect the members. I've seen this problem a lot, but this is a very convenient repro in a popular codebase :) --
[Issue 18882] __gshared not displaying in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18882 Manu changed: What|Removed |Added Assignee|nob...@puremagic.com|r.sagita...@gmx.de --
[Issue 18882] __gshared not displaying in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18882 --- Comment #1 from Manu --- Perhaps it's the extern(C++) that's the problem? That would explain why I have debug problems a lot. --
[Issue 18883] New: Revert workarounds expediting conversion of backend to D
https://issues.dlang.org/show_bug.cgi?id=18883 Issue ID: 18883 Summary: Revert workarounds expediting conversion of backend to D Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: slavo5...@yahoo.com At the time the following PRs were created, the host compiler 2.068.2 (I believe). It had mangling issues that prevented conversion of the DMD backend to D. Therefore, Walter, insisted on a number of workarounds to expedite conversion of the backed to D without having to wait for an updated host compiler. These workarounds should eventually be reverted (at least those that still remain after the conversion). https://github.com/dlang/dmd/pull/7416 -- See also https://github.com/dlang/dmd/pull/7505 https://github.com/dlang/dmd/pull/7523 https://github.com/dlang/dmd/pull/8249 --
[Issue 14086] Invalid extern C++ name for constructor / destructor
https://issues.dlang.org/show_bug.cgi?id=14086 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #2 from Manu --- I use pragma(mangle) to force the mangle for ctors to link to C++ ctor's just fine... in what way is the ABI incompatible? --
[Issue 18878] Short-circuiting && not behaving correctly
https://issues.dlang.org/show_bug.cgi?id=18878 Basile B. changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |DUPLICATE --- Comment #1 from Basile B. --- A fix is on the PR stack. *** This issue has been marked as a duplicate of issue 18115 *** --
[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE
https://issues.dlang.org/show_bug.cgi?id=18115 Basile B. changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #18 from Basile B. --- *** Issue 18878 has been marked as a duplicate of this issue. *** --
[Issue 18882] __gshared not displaying in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18882 --- Comment #2 from Rainer Schuetze --- See also issue 11024: there is no information about imports in the debug informations so you don't know which symbols are visible in the current scope and what their qualified name is. In D functions, the qualified name is used to find the requested symbol, too. This fails for extern(C/C++) functions that don't have the qualification, or if the symbol is in another module. You can still watch the variable using the fully qualified name (even for extern(C++) symbols), e.g. "dmd.globals.global". This actually matches C++ symbols that are in namespaces which also have to be specified. --
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 --- Comment #4 from Rainer Schuetze --- It seems I've messed up the defaults between Visual D and mago: you have to enable it in Tools->Options->Debugger->Mago. I think that being disabled is actually the better default as the vtable yields no additional information for most people. Unfortunately that build is also broken, as it tries to show [0] multiple times and fails. --
[Issue 18882] __gshared not displaying in debuginfo
https://issues.dlang.org/show_bug.cgi?id=18882 --- Comment #3 from Manu --- Hmm... yeah, that's unfortunate. I don't understand why it's hard to resolve the name. It's extern(C++), and it has no namespace supplied, so the correct symbol name should just be the mangled name, with no scope or anything. How is it that qualified names (with the D scope) can find a C++ symbol? The C++ symbol has no concept of D scope. Why does it need to be given a scope at all? --
[Issue 18879] !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 --- Comment #3 from Rainer Schuetze --- The distinction matters if keywords and operators are supposed to show different colors. --
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 --- Comment #5 from Manu --- Even if we can't see the symbol names, seeing the pointers might help matching values and confirm function order against C++ code that you can also see in the debugger. --
[Issue 18879] !is doesn't highlight correctly
https://issues.dlang.org/show_bug.cgi?id=18879 --- Comment #4 from Manu --- Oh? I didn't know they did... they're all blue by default on my setup :) --
