[Issue 17007] let std.math work in CTFE
https://issues.dlang.org/show_bug.cgi?id=17007 Issue 17007 depends on issue 20199, which changed state. Issue 20199 Summary: Make std.math.frexp work in CTFE https://issues.dlang.org/show_bug.cgi?id=20199 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 20199] Make std.math.frexp work in CTFE
https://issues.dlang.org/show_bug.cgi?id=20199 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7177 "Fix issues 20199 & 20200: make std.math.frexp & isPowerOf2 work in CTFE" was merged into master: - e7609cb8738e9105395a10b1d3871de8b5496f18 by Nathan Sashihara: Fix issues 20199 & 20200: make std.math.frexp & isPowerOf2 work in CTFE https://github.com/dlang/phobos/pull/7177 --
[Issue 20200] Make std.math.isPowerOf2 work for floating point numbers in CTFE
https://issues.dlang.org/show_bug.cgi?id=20200 Issue 20200 depends on issue 20199, which changed state. Issue 20199 Summary: Make std.math.frexp work in CTFE https://issues.dlang.org/show_bug.cgi?id=20199 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 20200] Make std.math.isPowerOf2 work for floating point numbers in CTFE
https://issues.dlang.org/show_bug.cgi?id=20200 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #7177 "Fix issues 20199 & 20200: make std.math.frexp & isPowerOf2 work in CTFE" was merged into master: - e7609cb8738e9105395a10b1d3871de8b5496f18 by Nathan Sashihara: Fix issues 20199 & 20200: make std.math.frexp & isPowerOf2 work in CTFE https://github.com/dlang/phobos/pull/7177 --
[Issue 17007] let std.math work in CTFE
https://issues.dlang.org/show_bug.cgi?id=17007 Issue 17007 depends on issue 20200, which changed state. Issue 20200 Summary: Make std.math.isPowerOf2 work for floating point numbers in CTFE https://issues.dlang.org/show_bug.cgi?id=20200 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 2420] string mixins are not considered in ddoc
https://issues.dlang.org/show_bug.cgi?id=2420 --- Comment #6 from FeepingCreature --- It's weird... if I look at Ddoc for a string mixin of aliases in a struct, I see the alias symbols (by name), but not any comments the mixin puts on them. --
[Issue 2643] Front-end should check for unimplemented interface functions
https://issues.dlang.org/show_bug.cgi?id=2643 RazvanN changed: What|Removed |Added Keywords||bootcamp CC||razvan.nitu1...@gmail.com --
[Issue 2646] Named mixins and member functions
https://issues.dlang.org/show_bug.cgi?id=2646
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #3 from RazvanN ---
Mixin templates are evaluated in the context of the instantiation scope. It
doesn't matter if a name is given to it or not. For example:
template Signal()
{
void connect() {};
}
class CheckBox
{
mixin Signal toggled;
}
void main()
{
auto a = new CheckBox();
a.connect();
}
This code compiles successfully. You don't have to call `a.toggled.connect`.
This is possible because connect is inserted in the scope of CheckBox (e.g. in
the overload set of that scope level).
Changing this would make mixing functions very difficult to work with.
Closing as invalid.
--
[Issue 2649] Inconsistent naming in TypeInfo derived classes
https://issues.dlang.org/show_bug.cgi?id=2649 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- There is a new hierarchy now. TypeInfoDeclarations are all VarDeclarations so they have the same names for most of the fields. All TypeInfoDeclarations inherit TypeInfoDeclaration so all inconsistencies are gone. Closing as WORKSFORME. --
[Issue 20204] need to fix ABI about registers using
https://issues.dlang.org/show_bug.cgi?id=20204 --- Comment #1 from KnightMare --- I mean need to fix documentation and add some samples that shows which registers will be used for it in Linux, Windows, _x64, ARM... like Linux/x64 convention uses RDI, RSI, RDX, RCX, R8, R9 for args left-to-right but D uses same registers for args right-to-left: extern (C) func( long a, long b, long c ) => C/Linux: RDI, RSI, RDX extern (D) func( long a, long b, long c ) => C/Linux: RDX, RSI, RDI --
[Issue 2853] Property overriding problem
https://issues.dlang.org/show_bug.cgi?id=2853
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #3 from RazvanN ---
This bug report is invalid. You have to use alias to pull in the number
overload set to Extension.
class Extension: Base
{
alias number = Base.number;
override int number(int value) // override setter
{
return 0;
}
void method()
{
printNumber(this.number); // calls Base.number
}
}
--
[Issue 2999] Return-type overloading should be error
https://issues.dlang.org/show_bug.cgi?id=2999 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #5 from RazvanN --- Running the second examples now yields: 1 2 This is the expected behavior. The first example still compiles. I assume that this is necessary in order to facilitate the compilation of the second example (for consistency reasons). In D, you have to implement both foo methods, so you must have the ability of overloading based on return type. Note that instantiating a C and calling foo will output an error. C c = new C; writeln(c.foo());// foo called with arguments () matches both definitions Closing as WORKSFORME. --
[Issue 20204] New: need to fix ABI about registers using
https://issues.dlang.org/show_bug.cgi?id=20204 Issue ID: 20204 Summary: need to fix ABI about registers using Product: D Version: D2 Hardware: All URL: https://dlang.org/spec/abi.html#register_conventions OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: blac...@bk.ru https://dlang.org/spec/abi.html#register_conventions D calling convention (for Linux/x64 in my case) uses registers in backward order. https://run.dlang.io/gist/run-dlang/7ed10bc2450b747cb65fdfbf6e375629 but such important info is missing from page about D register conventions. no info about x64 registers at all, and I can not find "reverse" or "backward" words too (I didnt read all page, just for registers) --
[Issue 2270] cast produces invalid arrays at runtime
https://issues.dlang.org/show_bug.cgi?id=2270 anonymous4 changed: What|Removed |Added Severity|normal |enhancement --- Comment #17 from anonymous4 --- I'd say it's by design. Maybe a warning will be fine. --
[Issue 20201] Make std.math.scalbn pure
https://issues.dlang.org/show_bug.cgi?id=20201 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7178 "Fix Issue 20201 - Make std.math.scalbn pure" was merged into master: - 083a0ac7430bf4cb74f62297f00e5189d7e3c71a by Nathan Sashihara: Fix Issue 20201 - Make std.math.scalbn pure https://github.com/dlang/phobos/pull/7178 --
