[Issue 23395] Regex leaks memory when used in multithreaded environment
https://issues.dlang.org/show_bug.cgi?id=23395 --- Comment #1 from anon --- This is especially important when using unit_threaded as this is also when you want to enable fsan --
[Issue 23475] Wrong printf deprecation message with ulong/long
https://issues.dlang.org/show_bug.cgi?id=23475 kinke changed: What|Removed |Added Status|NEW |RESOLVED CC||ki...@gmx.net Resolution|--- |INVALID --- Comment #1 from kinke --- Nope - Microsoft chose 32-bit for `long` (even when targeting 64-bit Windows!). You need to use `%lld` for `long long`, which is always 64-bit for all targets I know of. --
[Issue 23475] New: Wrong printf deprecation message with ulong/long
https://issues.dlang.org/show_bug.cgi?id=23475
Issue ID: 23475
Summary: Wrong printf deprecation message with ulong/long
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
On my Windows 8 system:
pragma(msg, size_t.sizeof); // 4
pragma(msg, ulong.sizeof); // 8
printf("%lu", ulong.init);
printfulong.d(33): Deprecation: argument `0LU` for format specification `"%lu"`
must be `uint`, not `ulong`
Surely %lu is the correct format specifier for ulong?!
Same for long:
printf("%ld", long.init);
printfulong.d(34): Deprecation: argument `0L` for format specification `"%ld"`
must be `int`, not `long`
--
[Issue 23472] scope(sucess) generate exception handling code.
https://issues.dlang.org/show_bug.cgi?id=23472 --- Comment #5 from kinke --- Almost - this basically corresponds to what the backend generates for the happy path without exception, except that the assignments to `ret` need to be constructions (`TOK.construct`) in order not to break in-place construction of the return value for non-POD return types. Such an invasive rewrite should be feasible in the frontend, but would presumably be quite a bit of work, for little gain IMO. --
[Issue 16599] Allow Template Constraint in Untemplated Function in Templated Struct
https://issues.dlang.org/show_bug.cgi?id=16599 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- The error is now: test.d(3): Error: cannot use function constraints for non-template functions. Use `static if` instead --
[Issue 16586] Implicit casting of enum with explicit int base type fails
https://issues.dlang.org/show_bug.cgi?id=16586 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from RazvanN --- I cannot reproduce this. It seems to have been fixed since 2.094.2 --
[Issue 23474] New: Grapheme should end after carriage return if not followed by line feed.
https://issues.dlang.org/show_bug.cgi?id=23474
Issue ID: 23474
Summary: Grapheme should end after carriage return if not
followed by line feed.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: ajiesk...@gmail.com
The only time a grapheme can continue after carriage return is when it's
followed by a line feed character. Otherwise it must break, even if followed by
an extending character: https://www.unicode.org/reports/tr29/tr29-41.html#GB4.
Thus
---
byGrapheme("\r\u0308").walkLength.writeln;
---
...should print 2, but it currently prints 1.
--
[Issue 23473] Need a way to disassemble an overload function without referencing a parent
https://issues.dlang.org/show_bug.cgi?id=23473 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 16538] Parameter head-const-ness shouldn't matter but does
https://issues.dlang.org/show_bug.cgi?id=16538 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --
[Issue 16535] writeln("a") is safe, stdout.writeln("a") is not
https://issues.dlang.org/show_bug.cgi?id=16535 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |phobos --
[Issue 15459] [REG2.065.0] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld
https://issues.dlang.org/show_bug.cgi?id=15459 RazvanN changed: What|Removed |Added CC||john.loughran.colvin@gmail. ||com --- Comment #15 from RazvanN --- *** Issue 16481 has been marked as a duplicate of this issue. *** --
[Issue 16481] invalid code accepted leading to linker error
https://issues.dlang.org/show_bug.cgi?id=16481 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #4 from RazvanN --- *** This issue has been marked as a duplicate of issue 15459 *** --
[Issue 23472] scope(sucess) generate exception handling code.
https://issues.dlang.org/show_bug.cgi?id=23472
--- Comment #4 from deadalnix ---
No, that is true in general. For instance, you exemple:
char inc(string s, ref int i) {
scope(success) i++;
if (s == null)
return 0;
if (s.length > 256)
return 1;
return s[i];
}
Is trivially equivalent to:
char inc(string s, ref int i) {
char ret;
if (s == null) {
ret = 0;
goto Exit;
}
if (s.length > 256) {
ret = 1:
goto Exit;
}
ret = s[i];
Exit:
i++;
return ret;
}
--
[Issue 16459] opDispatch gives obtuse error when dispatching to a function that doesn't exist
https://issues.dlang.org/show_bug.cgi?id=16459 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- This seems to have been improved now. In the first case it gives: test.d(14): Error: no property `doSomething` for `someObject` of type `test.SomeObject!int` test.d(14):potentially malformed `opDispatch`. Use an explicit instantiation to get a better error message So, at least it gives you a hint that this may be the problem. The idea is that currently the compiler cannot know if the error comes from passing the wrong arguments to opDispatch or if the error comes from within the innards of opDispatch that is why it just asks the user to call opDispatch explicitly. I think that until we find a way to deal with opDispatch this should be enough. --
[Issue 16447] make illegal for functions containing a `naked` asm block to return `auto`
https://issues.dlang.org/show_bug.cgi?id=16447 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #4 from RazvanN --- Why not? Assembly usage is for expert programmers so the compiler assumes that you know what you are doing. A third party tool check (like dscanner) is the way forward here. --
[Issue 16412] instance variable shadowing with inheritance
https://issues.dlang.org/show_bug.cgi?id=16412 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- This is correct code according to the spec: https://dlang.org/spec/class.html#fields This is not shadowing. Each class gets its own set and they don't conflict. --
[Issue 23473] Need a way to disassemble an overload function without referencing a parent
https://issues.dlang.org/show_bug.cgi?id=23473 --- Comment #2 from Dlang Bot --- @FeepingCreature created dlang/dmd pull request #14631 "Issue 23473: Improvement: Implement single-argument __traits(getOverloads) form." mentioning this issue: - Issue 23473: Improvement: Implement single-argument __traits(getOverloads) form. https://github.com/dlang/dmd/pull/14631 --
[Issue 16410] attribute inference for final methods of templated classes
https://issues.dlang.org/show_bug.cgi?id=16410 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #12 from RazvanN --- (In reply to Lodovico Giaretta from comment #10) > (In reply to Lodovico Giaretta from comment #9) > > Then a new question arises: why cannot attribute inference happen for > > *final* methods of templated classes? > > Small precisation: I mean *final override* methods. For final (non-virtual) > methods it already happens. The compiler cannot infer the attributes for final override methods because you already may have some constraints from the overriding function. For example, if the overriden function is @safe, the overriding function must also be @safe. Technically, the overriden function dictates the interface. I think it might be surprising to the attributes for overrides, even if they are final. I think we can close this issue as INVALID. --
[Issue 16399] template with func. ptr. argument and anon. func. in the template body, rejects its argument
https://issues.dlang.org/show_bug.cgi?id=16399 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- I cannot reproduce this with the latest version of master. --
[Issue 23473] Need a way to disassemble an overload function without referencing a parent
https://issues.dlang.org/show_bug.cgi?id=23473 FeepingCreature changed: What|Removed |Added Keywords||industry --
[Issue 23473] Need a way to disassemble an overload function without referencing a parent
https://issues.dlang.org/show_bug.cgi?id=23473 FeepingCreature changed: What|Removed |Added Summary|Need a way to disassemble |Need a way to disassemble |an overload function|an overload function ||without referencing a ||parent --
[Issue 23473] Need a way to disassemble an overload function
https://issues.dlang.org/show_bug.cgi?id=23473
--- Comment #1 from FeepingCreature ---
Oops, pressed return too soon.
Consider this code:
--- b.d
void first(int) { }
--- a.d
import b : foo = first;
import c : foo = second;
void main() {
foo(1); // works
foo("hello"); // works
alias overloads = __traits(getOverloads, __traits(parent, foo),
__traits(identifier, foo));
static assert(overloads.length == 2);
}
--- c.d
void second(string) { }
Because the overload we want is not of a struct or class, we use the common
pattern, for example used in https://dlang.org/blog/category/algorithms/ , to
get "the module" the overload is in. But there is no such module, because the
overload is formed from two other modules that don't even use the same
identifier for it.
There should be an overload or trait alternative to getOverloads that operates
on a symbol directly.
--
[Issue 23473] New: Need a way to disassemble an overload function
https://issues.dlang.org/show_bug.cgi?id=23473 Issue ID: 23473 Summary: Need a way to disassemble an overload function Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: default_357-l...@yahoo.de --
[Issue 23461] dmd: src/dmd/backend/cod1.d:2037: Assertion false failed
https://issues.dlang.org/show_bug.cgi?id=23461 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #14622 "fix Issue 23461 - dmd: src/dmd/backend/cod1.d:2037: Assertion false f…" was merged into stable: - 8ae381e37aa6a0b6578581912b707cc186e374f8 by Walter Bright: fix Issue 23461 - dmd: src/dmd/backend/cod1.d:2037: Assertion false failed https://github.com/dlang/dmd/pull/14622 --
[Issue 21301] Wrong values being passed in long parameter list
https://issues.dlang.org/show_bug.cgi?id=21301 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #14629 "fix Issue 21301 - Wrong values being passed in long parameter list" was merged into master: - 0317665d516966417e3a0ceeb12b0ede9cee862b by Walter Bright: fix Issue 21301 - Wrong values being passed in long parameter list https://github.com/dlang/dmd/pull/14629 --
