[Issue 21063] getLinkage is wrong for forward reference extern(C++) class
https://issues.dlang.org/show_bug.cgi?id=21063 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #11438 "Fix 21063 - getLinkage fails with forward references" was merged into stable: - 6134972c17e29e9d193d777013fa67df17451434 by Geod24: Fix 21063 - getLinkage fails with forward references Use the same code as other traits, e.g. getClassInstanceSize, use. https://github.com/dlang/dmd/pull/11438 --
[Issue 21059] install.sh: posix_terminal returns false on Linux Mint 20
https://issues.dlang.org/show_bug.cgi?id=21059 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/installer pull request #463 "Fixes issue 21059: installer fails when piped on Posix." was merged into stable: - 719ebf6f472b2b2d58b56fef2aebbf530cc5bcf3 by Bastiaan Veelo: Fixes issue 21059. The assumption that $SHLVL increases when the script is run does not always hold. $SHLVL does not increase if the script is piped into bash, thereby failing to detect Posix. If the default terminal shell is not bash, $SHLVL might also be 1 on Posix. https://github.com/dlang/installer/pull/463 --
[Issue 12223] __traits(getMember,...) needed for aliases
https://issues.dlang.org/show_bug.cgi?id=12223 --- Comment #4 from Dlang Bot --- @rmanthorpe created dlang/dmd pull request #11442 "Issue 12223 - __traits(getMember,...) needed for aliases" mentioning this issue: - Issue 12223 - __traits(getMember,...) needed for aliases Add `__traits(child, p, c)` to interpret `c` with the `this` context set to `p`. This is the opposite of `__traits(parent, c)`. `c` should be a symbol mising it's `this` context, such an an alias to a member of `p`. https://github.com/dlang/dmd/pull/11442 --
[Issue 21035] wrong code when uses struct's methods of .init value
https://issues.dlang.org/show_bug.cgi?id=21035 --- Comment #3 from Stefan Koch --- What happens is that a `memcpy` fails which seems to be done executing `data[0 .. str.length] = str` why that happens is still under investigation --
[Issue 21064] New: setCookieJar/caInfo in std.net.curl cannot handle the non-ASCII paths
https://issues.dlang.org/show_bug.cgi?id=21064
Issue ID: 21064
Summary: setCookieJar/caInfo in std.net.curl cannot handle the
non-ASCII paths
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: zan77...@nifty.com
Some of the functions provided by std.net.curl handle paths, such as
setCookieJar and caInfo. But they cannot handle the non-ASCII paths.
-
import std;
void makeCookieFile(string dir)
{
if (!dir.exists)
mkdirRecurse(dir);
auto client = HTTP();
client.setCookieJar(dir.buildPath("cookie.txt"));
get("https://dlang.org;, client);
}
void main()
{
auto asciiPath = "abcde";
auto nonAsciiPath = "あいうえお";
makeCookieFile(asciiPath);
makeCookieFile(nonAsciiPath);
// Assertion failure, the nonAsciiPath is not including anything
assert(dirEntries(asciiPath,SpanMode.shallow).map!"a.name".equal(
dirEntries(nonAsciiPath, SpanMode.shallow).map!"a.name"));
}
-
core.exception.AssertError@src\main.d(19): Assertion failure
-
I did a little research, but I couldn't figure out what character code should
be passed to Curl... Probably that is the system-dependent MBCS(NOT UTF-8).
https://curl.haxx.se/libcurl/c/CURLOPT_COOKIEJAR.html
--
[Issue 14458] very slow ubyte[] assignment (dmd doesn't use memset)
https://issues.dlang.org/show_bug.cgi?id=14458 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #11437 "fix Issue 14458 - very slow ubyte[] assignment (dmd doesn't use memset)" was merged into master: - b8f31faeb720f25cfa672dcb7ae0d72d8efd2a0c by Walter Bright: fix Issue 14458 - very slow ubyte[] assignment (dmd doesn't use memset) https://github.com/dlang/dmd/pull/11437 --
[Issue 9490] 'this' is not found when expression is in parentheses
https://issues.dlang.org/show_bug.cgi?id=9490 --- Comment #7 from Dlang Bot --- dlang/dmd pull request #11439 "[dmd-cxx] fix issue 9490 - 'this' is not found when expression is in parentheses" was merged into dmd-cxx: - 3d5716d46a30122809ae7c2b58f07f6b262afcba by Stian Gulpen: fix issue 9490 - 'this' is not found when expression is in parentheses https://github.com/dlang/dmd/pull/11439 --
[Issue 19663] On x86_64 the fabs intrinsic should use SSE
https://issues.dlang.org/show_bug.cgi?id=19663 --- Comment #2 from Basile-z --- BTW option 3 doesn't work. --
[Issue 21063] getLinkage is wrong for forward reference extern(C++) class
https://issues.dlang.org/show_bug.cgi?id=21063 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @Geod24 created dlang/dmd pull request #11438 "Fix 21063 - getLinkage fails with forward references" fixing this issue: - Fix 21063 - getLinkage fails with forward references Use the same code as other traits, e.g. getClassInstanceSize, use. https://github.com/dlang/dmd/pull/11438 --
[Issue 21063] New: getLinkage is wrong for forward reference extern(C++) class
https://issues.dlang.org/show_bug.cgi?id=21063
Issue ID: 21063
Summary: getLinkage is wrong for forward reference extern(C++)
class
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dl...@vild.io
```
static assert(__traits(getLinkage, Klass) == "C++"); // Succeeds
pragma(msg, __traits(getLinkage, Klass)); // Gets D linkage (Wrong)
extern (C++) class Klass { void a() {} }
static assert(__traits(getLinkage, Klass) == "C++");
pragma(msg, __traits(getLinkage, Klass)); // Correct linkage
```
--
[Issue 19663] On x86_64 the fabs intrinsic should use SSE
https://issues.dlang.org/show_bug.cgi?id=19663 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All --- Comment #1 from Walter Bright --- Partial fix: https://github.com/dlang/phobos/pull/7561 --
[Issue 21062] Compiler produces wildly different diagnostics based on variable names
https://issues.dlang.org/show_bug.cgi?id=21062 Basile-z changed: What|Removed |Added Keywords||diagnostic CC||b2.t...@gmx.com Summary|Diagnostic for |Compiler produces wildly |'synchronized' used as a|different diagnostics based |variable name should be |on variable names |improved| --- Comment #2 from Basile-z --- yeah it's a keyword, so parser error. Maybe just "cannot use `%s` as identifier because this is a keyword" and as errorSupplemental() "append a trailing underscore" --
[Issue 21062] Diagnostic for 'synchronized' used as a variable name should be improved
https://issues.dlang.org/show_bug.cgi?id=21062 Andrej Mitrovic changed: What|Removed |Added Summary|Compiler produces wildly|Diagnostic for |different diagnostics based |'synchronized' used as a |on variable names |variable name should be ||improved --
[Issue 21062] Compiler produces wildly different diagnostics based on variable names
https://issues.dlang.org/show_bug.cgi?id=21062 --- Comment #1 from Andrej Mitrovic --- So apparently I forgot synchronized is a statement, but the compiler should emit a better diagnostic. I'll rename the issue. --
[Issue 21062] New: Compiler produces wildly different diagnostics based on variable names
https://issues.dlang.org/show_bug.cgi?id=21062
Issue ID: 21062
Summary: Compiler produces wildly different diagnostics based
on variable names
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
DMD 2.093 (also tested with 2.089)
This is OK:
-
struct S
{
public time_t time;
public bool synced;
}
-
$ dmd -c test.d
> test.d(9,19): Error: undefined identifier `time_t`, did you mean variable
> `time`?
But look at this:
-
struct S
{
public time_t time;
public bool synchronized;
}
-
$ dmd -c test.d
> test.d(4): Error: no identifier for declarator bool
> test.d(4): Error: declaration expected following attribute, not ;
There is no mention of `time_t` being undefined.
--
