Re: Finding source of typeid use

On 08/07/2017 2:35 AM, Nicholas Wilson wrote: On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows

[Issue 6410] Few common exceptions in std.exception

https://issues.dlang.org/show_bug.cgi?id=6410 Jonathan M Davis changed: What|Removed |Added CC|

Re: Application settings

On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote: On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote: On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then

Re: Release fluent-asserts 0.6.0

On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote: Any feedback is appreciated. Thanks, Bogdan Hi, if you're just looking for other ideas, you might want to look at adding capabilities like in the java hamcrest matchers. You might also want to support regular expression matches

Re: DCompute development

On Wednesday, 5 July 2017 at 18:48:57 UTC, Luís Marques wrote: On Wednesday, 5 July 2017 at 09:41:40 UTC, Nicholas Wilson wrote: Now that I've (finally) finished my honours thesis, I've got time to start working on dcompute again. I'd like to invite anyone interested in helping to develop

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, 8 July 2017 at 02:23:53 UTC, Jonathan M Davis wrote: On Saturday, July 8, 2017 12:55:46 AM MDT FoxyBrown via Digitalmars-d wrote: I came across some error in heap sort. Was erroring out on the wrong. A few lines below the assert existed but no error message associated, why is it

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, July 8, 2017 12:55:46 AM MDT FoxyBrown via Digitalmars-d wrote: > I came across some error in heap sort. Was erroring out on the > wrong. A few lines below the assert existed but no error message > associated, why is it so hard to not write a few extra EXTREMELY > helpful error

DIP 1007--"future symbol"--Has Been Accepted

Congratulations to Mihails Strasuns, a.k.a. Dicebot, on the acceptance of his DIP 1007, '"future symbol" Compiler Concept'! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md Although the proposal recommended that the feature be implemented only internally for DRuntime initially,

[Issue 9693] unclear scoping behaviour of declarations made in static if conditions

https://issues.dlang.org/show_bug.cgi?id=9693 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 15373] Segfault when using typeid on extern(C++) class with virtual functions

https://issues.dlang.org/show_bug.cgi?id=15373 Vladimir Panteleev changed: What|Removed |Added Keywords|

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, July 8, 2017 1:51:34 AM MDT Moritz Maxeiner via Digitalmars-d wrote: > On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote: > > [...] > > It should be mandatory that all asserts, throws, etc provide > > correct information about not only the point of the error but > > also the

[Issue 15640] type inference in variadic array params not working for classes

https://issues.dlang.org/show_bug.cgi?id=15640 Vladimir Panteleev changed: What|Removed |Added Hardware|x86_64 |All

Re: Automatic invariant generation

On Friday, July 7, 2017 2:31:42 PM MDT Nicholas Wilson via Digitalmars-d wrote: > On Friday, 7 July 2017 at 14:17:34 UTC, Jonathan M Davis wrote: > > What does it even do? > > asserts that the this pointer is not null, apparently which is > annoying because you'd crash anyway. I suppose you might

Re: Go Your Own Way (Part One: The Stack)

On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars) I read this as

[Issue 15140] std.experimental.allocator.building_blocks.free_list.FreeList leaks memory

https://issues.dlang.org/show_bug.cgi?id=15140 Vladimir Panteleev changed: What|Removed |Added CC|

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote: [...] It should be mandatory that all asserts, throws, etc provide correct information about not only the point of the error but also the location and what caused it. [...] Error messages are sensible when they provide context (e.g.

[Issue 11405] rdmd should limit its tmp cache

https://issues.dlang.org/show_bug.cgi?id=11405 Vladimir Panteleev changed: What|Removed |Added Component|dmd

Re: Release candidates vibe.d 0.8.0-rc.6 and vibe-core 1.0.0-rc.4

There have been two more regression fixes: - (De)serialization of self-referential types was broken (@safe related compile error) - The .parentPath property of the new path types in vibe-core was broken The release date is still scheduled for Monday.

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

https://issues.dlang.org/show_bug.cgi?id=16650 Vladimir Panteleev changed: What|Removed |Added Keywords||C++

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

https://issues.dlang.org/show_bug.cgi?id=15587 --- Comment #2 from Vladimir Panteleev --- In this particular case, the easiest workaround is to use pragma(mangle), right? I understand that this is more useful for C++ functions, whose mangling is non-trivial.

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, 8 July 2017 at 01:01:38 UTC, Vladimir Panteleev wrote: On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote: It would be easy to find all the bad asserts? Does Dscanner have a rule to detect assert and enforce calls without a message? We should have it enabled for Phobos.

Re: Finding source of typeid use

On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows why, which explains why I only get the const

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

https://issues.dlang.org/show_bug.cgi?id=16650 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: Go Your Own Way (Part One: The Stack)

On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars)

Re: Go Your Own Way (Part One: The Stack)

On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via Digitalmars-d-announce wrote: > On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- > announce wrote: [...] > > The implicit slice is one of what I see as D's design flaws and > > brings up a number of problems.

Re: All asserts need to have messages attached! Explicit as possible!

On 08.07.2017 02:55, FoxyBrown wrote: I came across some error in heap sort. Was erroring out on the wrong. A few lines below the assert existed but no error message associated, why is it so hard to not write a few extra EXTREMELY helpful error messages? assert(isHeap(r), "This is an ERROR AT

Re: Go Your Own Way (Part One: The Stack)

On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- announce wrote: > I would add a note to the "static arrays are interchangeable with > dynamic arrays" saying that you can... and probably should > explicitly slice them with `[]`. > > The implicit slice is one of what I see as

Re: All asserts need to have messages attached! Explicit as possible!

On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote: It would be easy to find all the bad asserts? Does Dscanner have a rule to detect assert and enforce calls without a message? We should have it enabled for Phobos.

All asserts need to have messages attached! Explicit as possible!

I came across some error in heap sort. Was erroring out on the wrong. A few lines below the assert existed but no error message associated, why is it so hard to not write a few extra EXTREMELY helpful error messages? assert(isHeap(r), "This is an ERROR AT THIS

Re: Go Your Own Way (Part One: The Stack)

On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote: On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you

[Issue 5276] Template compilation uses much more memory than G++ 4.8

https://issues.dlang.org/show_bug.cgi?id=5276 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: Application settings

On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote: On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then save when necessary(possibly be efficient at it, but

[Issue 5276] Template compilation uses much more memory than G++ 4.8

https://issues.dlang.org/show_bug.cgi?id=5276 Vladimir Panteleev changed: What|Removed |Added Hardware|x86 |All

Re: Go Your Own Way (Part One: The Stack)

On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements

Foster parents for Phobos modules wanted

With which Phobos module(s) are you most familiar with? -> https://github.com/dlang/phobos/pull/5573 Being on the Phobos team is _not_ a requirement - everyone can help out!

[Issue 17482] [REG 2.074] comile error: Comparing Nullable!Variant with basic type

https://issues.dlang.org/show_bug.cgi?id=17482 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 17482] [REG 2.074] comile error: Comparing Nullable!Variant with basic type

https://issues.dlang.org/show_bug.cgi?id=17482 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/a7ea880eb24a36e09e50de7b8b32d941110aa630 Fix issue 17482: Fix Nullable!Variant equality checks.

[Issue 10185] Linker errors with rdmd

https://issues.dlang.org/show_bug.cgi?id=10185 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: Application settings

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then save when necessary(possibly be efficient at it, but probably doesn't matter). Simply json an array and save and load it,

[Issue 5077] std.algorithm.schwartzSort is slow

https://issues.dlang.org/show_bug.cgi?id=5077 Vladimir Panteleev changed: What|Removed |Added Hardware|x86 |All

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

https://issues.dlang.org/show_bug.cgi?id=16564 --- Comment #6 from Andrei Alexandrescu --- @Temtaime should this stay open? --

Re: Vibe.d - very low performance

Am 07.07.2017 um 21:27 schrieb FoxyBrown: On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote: Am 06.07.2017 um 09:27 schrieb Marek: https://www.techempower.com/benchmarks/#section=data-r14=ph=plaintext C++, Java and Go frameworks have very high performance. Vibe.d is supposed to

[Issue 12372] Forward reference error with auto type inference in overloaded functions

https://issues.dlang.org/show_bug.cgi?id=12372 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: Automatic invariant generation

Steven Schveighoffer wrote: On 7/7/17 4:26 PM, ketmar wrote: Steven Schveighoffer wrote: On 7/7/17 2:27 PM, ketmar wrote: ketmar wrote: yeah, this is annoying. while checking for "null this" in *class* method may look hacky tbh, i see nothing wrong in checking for "null this" even in

Re: Application settings

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then save when necessary(possibly be efficient at it, but probably doesn't matter). Simply json an array and save and load it,

Re: Automatic invariant generation

On 7/7/17 4:26 PM, ketmar wrote: Steven Schveighoffer wrote: On 7/7/17 2:27 PM, ketmar wrote: ketmar wrote: yeah, this is annoying. while checking for "null this" in *class* method may look hacky tbh, i see nothing wrong in checking for "null this" even in class methods, but this is a

Re: Checked vs unchecked exceptions

On Friday, 7 July 2017 at 18:48:31 UTC, Marco Leise wrote: Am Thu, 06 Jul 2017 13:16:23 + schrieb Moritz Maxeiner : That's right, but still one can distill general ideas and leave implementations details aside. Pretty much like the Platonic Ideal. Then you look at what

Re: Go Your Own Way (Part One: The Stack)

On 7/7/17 4:10 PM, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Since

Re: Automatic invariant generation

Steven Schveighoffer wrote: On 7/7/17 2:27 PM, ketmar wrote: ketmar wrote: yeah, this is annoying. while checking for "null this" in *class* method may look hacky tbh, i see nothing wrong in checking for "null this" even in class methods, but this is a completely different story. In

Re: Go Your Own Way (Part One: The Stack)

On 07-07-17 22:10, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Only for

Re: Go Your Own Way (Part One: The Stack)

On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib

Re: Automatic invariant generation

On 7/7/17 2:27 PM, ketmar wrote: ketmar wrote: yeah, this is annoying. while checking for "null this" in *class* method may look hacky tbh, i see nothing wrong in checking for "null this" even in class methods, but this is a completely different story. In *final* methods maybe. Virtual

Re: Go Your Own Way (Part One: The Stack)

On 7/7/2017 12:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. I would think it has to do this, since actually calling a function would generate a new stack frame. Yes and yes.

Application settings

What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then save when necessary(possibly be efficient at it, but probably doesn't matter). Simply json an array and save and load it, or is there a better way? Ideally, I'd like to store

Re: Application settings

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: What's the "best" way to do this? I want something I can simply load at startup in a convenient and easy way then save when necessary(possibly be efficient at it, but probably doesn't matter). Simply json an array and save and load it,

Re: Go Your Own Way (Part One: The Stack)

On 7/7/17 3:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and

Re: Go Your Own Way (Part One: The Stack)

On 7/7/17 8:59 AM, Mike Parker wrote: This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC

Re: Vibe.d - very low performance

On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote: Am 06.07.2017 um 09:27 schrieb Marek: https://www.techempower.com/benchmarks/#section=data-r14=ph=plaintext C++, Java and Go frameworks have very high performance. Vibe.d is supposed to have similar performance, but in fact vibe.d

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

https://issues.dlang.org/show_bug.cgi?id=17619 Martin Krejcirik changed: What|Removed |Added Keywords||symdeb --

Re: Vibe.d - very low performance

On 2017-07-07 20:22, Marek wrote: What do you mean by 'scalability'? Raw tornado or bottle frameworks have much better results than vibe.d. Python and Ruby have GIL so they can't use threads in their standard implementations. They have much better results anyway. I think that vibe.d didn't

Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

On 07/07/2017 08:29 PM, alex_ca wrote: I'm having trouble understanding why in some cases a double value will be rounded up and other times down, for the same code. Here's a snippet with code I tried to debug: int getNumberOfStitchesForRowLength(double rowLength) { writeln("input

Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

On 07/07/2017 11:29 AM, alex_ca wrote: > input 2.5 10 10 > stitches: 2.5 -> 2 > I expect: 3 That's because what is printed as 2.5 is actually a little less than that. (Try printing with a format string like "%.20f".) The common way of dealing with this issue is to add 0.5 before the

[Issue 13153] dlang.org: provide version-specific documentation of the language and stdlib

https://issues.dlang.org/show_bug.cgi?id=13153 --- Comment #7 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/b0a06c7deab4b8093d6e1fe7f592001d60a3e7c1 Fix issue 13153 - Add a version chooser to DDoc

Re: Checked vs unchecked exceptions

Am Thu, 06 Jul 2017 13:16:23 + schrieb Moritz Maxeiner : > On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote: > > Am Thu, 06 Jul 2017 01:31:44 + > > schrieb Moritz Maxeiner : > > > >> But to be clear (and the title and description of any

[Issue 4354] Phobos should expose per-thread errno

https://issues.dlang.org/show_bug.cgi?id=4354 --- Comment #4 from Andrei Alexandrescu --- This is a reproducible problem on Windows (at least with wine). We use a C small file in druntime (src/core/stdc/errno.c) to make sure we use the C macro. Far as I can tell the same

Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

Hi, I'm having trouble understanding why in some cases a double value will be rounded up and other times down, for the same code. Here's a snippet with code I tried to debug: int getNumberOfStitchesForRowLength(double rowLength) { writeln("input ", rowLength, " ",

Re: Automatic invariant generation

ketmar wrote: yeah, this is annoying. while checking for "null this" in *class* method may look hacky tbh, i see nothing wrong in checking for "null this" even in class methods, but this is a completely different story.

Re: Automatic invariant generation

Steven Schveighoffer wrote: Hm... it doesn't look like an invariant, it just looks like an inserted assert inside every function. An incorrect assert, IMO: struct Foo { int x; void foo() {} } void main() { Foo *foo; foo.foo(); // shouldn't assert, wouldn't crash anyway. }

Re: Vibe.d - very low performance

On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote: This is a scalability issue, which should hopefully be fixed with 0.8.0. I'll open a PR once that is out. Basically with the version that was used in the last benchmark round, it didn't scale at all, and they use a server with many

Re: Address of a lambda

On 07/07/2017 10:52 AM, Ali Çehreli wrote: > a solution with the addition of the > keyword 'delegate': As ag0aep6g explained, the 'delegate' keyword was not necessary there. A case where it's needed is when defining a variable. The following code compiles if 'delegate' keyword is present:

[Issue 17526] Add a set method for AA

https://issues.dlang.org/show_bug.cgi?id=17526 --- Comment #5 from Vladimir Panteleev --- BTW, the performance use case of the proposed set method (which I called getOrAdd in my hashmap implementation): struct S { int i, j, k, l, m; /* etc. */ } S[int] aa; //

[Issue 17619] New: [REG2.072] Wrong debug line information with single line loops

https://issues.dlang.org/show_bug.cgi?id=17619 Issue ID: 17619 Summary: [REG2.072] Wrong debug line information with single line loops Product: D Version: D2 Hardware: All OS: Linux Status: NEW

[Issue 17526] Add a set method for AA

https://issues.dlang.org/show_bug.cgi?id=17526 --- Comment #4 from Vladimir Panteleev --- (In reply to hsteoh from comment #3) > What about a const overload to opIndexAssign that lets you assign to a new > key, but aborts if the key already exists? I'm not

Re: Can we get rid of non-raw write?

Vetoed after several years of nothing: https://issues.dlang.org/show_bug.cgi?id=9776#c7 I'm getting really fucking tired of D making up excuses to throw "do the right thing by default" straight into the gutter. D steering didn't used to be this way, and that was exactly what make D into

Re: Address of a lambda

On 07/07/2017 07:33 PM, FoxyBrown wrote: In gtk, we routinly have to use delegates for callbacks. But the methods that accept these delegates want the address of the delegate, I don't think that's true. As far as I can tell, this is the signature of addOnDelete [1]: gulong

Re: Address of a lambda

On Friday, 7 July 2017 at 17:52:25 UTC, Ali Çehreli wrote: On 07/07/2017 10:33 AM, FoxyBrown wrote: > [...] the methods > [...] I'm not a user but I don't think it's right. According to the following, it takes a delegate: [...] Thanks, I guess one doesn't need to pass the address(I copied

Re: Address of a lambda

On 07/07/2017 10:33 AM, FoxyBrown wrote: > In gtk, we routinly have to use delegates for callbacks. But the methods > that accept these delegates want the address of the delegate, I'm not a user but I don't think it's right. According to the following, it takes a delegate:

Re: Address of a lambda

On Friday, 7 July 2017 at 17:33:33 UTC, FoxyBrown wrote: In gtk, we routinly have to use delegates for callbacks. But the methods that accept these delegates want the address of the delegate, this prevents us from being able to pass a lambda in directly, but there really is not reason why we

[Issue 12949] Project compilation time increased by 64% for last half year

https://issues.dlang.org/show_bug.cgi?id=12949 --- Comment #5 from Vladimir Panteleev --- (In reply to Rainer Schuetze from comment #3) > An error occured while loading the graph data (data/data.json) > parsererror: SyntaxError: Unexpected end of JSON input

[Issue 12949] Project compilation time increased by 64% for last half year

https://issues.dlang.org/show_bug.cgi?id=12949 --- Comment #4 from Vladimir Panteleev --- (In reply to Rainer Schuetze from comment #3) > What about "Is D slim yet?" http://digger.k3.1azy.net/trend/ produces an > error for me: > > An error occured while

[Issue 12949] Project compilation time increased by 64% for last half year

https://issues.dlang.org/show_bug.cgi?id=12949 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de

[Issue 9776] Make raw write mode the default

https://issues.dlang.org/show_bug.cgi?id=9776 Vladimir Panteleev changed: What|Removed |Added Status|REOPENED

[Issue 12949] Project compilation time increased by 64% for last half year

https://issues.dlang.org/show_bug.cgi?id=12949 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 7623] Allow aliasing of symbols of an aliased subtype

https://issues.dlang.org/show_bug.cgi?id=7623 --- Comment #1 from Vladimir Panteleev --- Pretty sure this can't work for the same reason `alias foo.isOne isTwo` doesn't work - you can't alias an expression. --

Address of a lambda

In gtk, we routinly have to use delegates for callbacks. But the methods that accept these delegates want the address of the delegate, this prevents us from being able to pass a lambda in directly, but there really is not reason why we shouldn't be able to do this? Fine: void main() { bool

[Issue 12995] Include UDA in JSON output

https://issues.dlang.org/show_bug.cgi?id=12995 Vladimir Panteleev changed: What|Removed |Added Keywords||json

[Issue 16531] Protected members not accessible in delegate bodies

https://issues.dlang.org/show_bug.cgi?id=16531 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 13605] Add ability to `version` a module declaration

https://issues.dlang.org/show_bug.cgi?id=13605 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 16499] Misleading error message for 'in' operator with wrong argument

https://issues.dlang.org/show_bug.cgi?id=16499 Vladimir Panteleev changed: What|Removed |Added CC|

[Issue 3905] Wrong error message with wrong opBinary("in")

https://issues.dlang.org/show_bug.cgi?id=3905 Vladimir Panteleev changed: What|Removed |Added Status|REOPENED

Re: GDB behaves strange with DMD

Dne 4. 7. 2017 v 13:46 Gorthad napsal(a): As you see, GDB seems to have wrong info about line numbers. This is acually a regression since 2.072. I'll file a bug report. -- mk

[Issue 17618] parse booktables manually to check whether symbols haven't been mentioned

https://issues.dlang.org/show_bug.cgi?id=17618 --- Comment #1 from Seb --- See also: https://github.com/dlang-community/D-Scanner/issues/494 --

[Issue 17618] New: parse booktables manually to check whether symbols haven't been mentioned

https://issues.dlang.org/show_bug.cgi?id=17618 Issue ID: 17618 Summary: parse booktables manually to check whether symbols haven't been mentioned Product: D Version: D2 Hardware: x86_64 OS: Linux

[Issue 7179] Hash algorithm vulnerable to algorithmic complexity attacks

https://issues.dlang.org/show_bug.cgi?id=7179 Vladimir Panteleev changed: What|Removed |Added Priority|P2 |P1

[Issue 9137] A function that equals to "out of scope" action for manual lifetime management

https://issues.dlang.org/show_bug.cgi?id=9137 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 9139] `destroy` is dangerous and inconsistent

https://issues.dlang.org/show_bug.cgi?id=9139 Vladimir Panteleev changed: What|Removed |Added Keywords|wrong-code |

[Issue 13397] allow postfix function attributes like 'safe', 'system' and so on without '@'

https://issues.dlang.org/show_bug.cgi?id=13397 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 6410] Few common exceptions in std.exception

https://issues.dlang.org/show_bug.cgi?id=6410 RazvanN changed: What|Removed |Added CC|

[Issue 17308] [TEST/PROCESS] Beta releases should not be built with -release

https://issues.dlang.org/show_bug.cgi?id=17308 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 15005] Coverage files start with a dash character when using full pathname for source files with -cov

https://issues.dlang.org/show_bug.cgi?id=15005 Vladimir Panteleev changed: What|Removed |Added Hardware|x86_64 |All

  1   2   >