[Issue 20113] Cannot find source code for runtime library file 'object.d' when the path contains '~'
https://issues.dlang.org/show_bug.cgi?id=20113 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #10309 "[dmd-cxx] fix Issue 20113 - Cannot find source code for runtime library file 'object.d' when the path contains '~'" was merged into dmd-cxx: - 1e44c0ba6161ccc9074b45306abf5aabbeedd6be by Iain Buclaw: [dmd-cxx] fix Issue 20113 - Cannot find source code for runtime library file 'object.d' when the path contains '~' https://github.com/dlang/dmd/pull/10309 --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 Jon Degenhardt changed: What|Removed |Added CC||jrdemail2000-dl...@yahoo.co ||m --- Comment #5 from Jon Degenhardt --- Correct handling of invalid UTF sequences is often known only by the application. That is, it is task dependent. And in some applications, the appropriate handling may not be known until runtime, making compile-time decisions problematic. A related piece of the puzzle is that in many high performance string processing applications, it is useful to switch between modes of processing where strings are handled as bytes for some algorithms, then switch back to modes where strings are character sequences. When operating as bytes, UTF interpretation is not needed or desired (so no detection of invalid UTF sequences). But when algorithms are operating on characters, then invalid UTF detection/handling is desired/required. (Note: Many of these algorithms are possible because ASCII characters in UTF-8 can be used as single byte markers without interpretation of other parts of the byte stream.) This makes it difficult for libraries to implement a single policy and still nicely support the wide range of application use-cases. Especially when there may be many layers of code between the application layer making a call and the lower level function where opportunity for detection occurs. As an application developer, what I'd really like to have is a magical context object where the current detection and handling policies are set, and have all code invoked with the scope of that object obey them. I'd gladly take a performance hit to get it. This may too big change, but it's worth considering how well other solutions compare from an application development perspective. --
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #10312 "fix Issue 20131 - Bad codegen from inline asm LOCK CMPXCHG; possible …" was merged into master: - e26754056f0e671edbcdb80b9507780fa078907d by Walter Bright: fix Issue 20131 - Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing https://github.com/dlang/dmd/pull/10312 --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 --- Comment #4 from Vladimir Panteleev --- (In reply to Walter Bright from comment #1) > Over time, common practice has evolved from rejecting malformed UTF to > replacing it with replacementDchar, which enables the application (like a > web browser) to continue processing. BTW, I don't think this is quite correct. Web browsers both raise an error (in the dev console) AND continue processing. By using replacementDchar implicitly, D programs would not know that there was ever a problem. --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 Vladimir Panteleev changed: What|Removed |Added CC||dlang-bugzilla@thecybershad ||ow.net --- Comment #3 from Vladimir Panteleev --- (In reply to Walter Bright from comment #1) > Over time, common practice has evolved from rejecting malformed UTF to > replacing it with replacementDchar, which enables the application (like a > web browser) to continue processing. In applications where not crashing is preferrable to corrupting data, yes, but I don't think we can make that decision in place of the user. Corrupted data spreads and seeps into archives and can be very hard to rectify once it's discovered, but crashes are immediately visible and usually easily fixable. > Code should also be faster with this change. So should either assuming that the strings are valid, or throwing Errors instead of Exceptions, right? --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14519 --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20134 --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @WalterBright updated dlang/phobos pull request #7144 "fix Issue 20134 - autodecode should use replacementDchar rather than throwing on invalid" fixing this issue: - fix Issue 20134 - autodecode should use replacementDchar rather than throwing on invalid https://github.com/dlang/phobos/pull/7144 --
[Issue 20134] autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 --- Comment #1 from Walter Bright --- Over time, common practice has evolved from rejecting malformed UTF to replacing it with replacementDchar, which enables the application (like a web browser) to continue processing. Code should also be faster with this change. --
[Issue 20134] New: autodecode should use replacementDchar rather than throwing on invalid
https://issues.dlang.org/show_bug.cgi?id=20134 Issue ID: 20134 Summary: autodecode should use replacementDchar rather than throwing on invalid Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Currently, when the autodecoder encounters an invalid UTF sequence, it throws a UTFexception. In contrast, the byUTF conversions return a replacementDchar instead, as does foreach() when decoding. This enhancement would make the behavior consistent, with the additional benefits of character processing being @nogc and nothrow and even pure. --
[Issue 20116] Wrong delegate type when taking address of inout member function
https://issues.dlang.org/show_bug.cgi?id=20116 --- Comment #3 from Harry Vennik --- That is an interesting approach. Looks like that would fix this particular issue. But could you please elaborate on the effects of such semantic in the different, but related, case of Issue 15651? --
[Issue 20133] New: [REG2.084.0] Bogus slice assignment in recursive CTFE call
https://issues.dlang.org/show_bug.cgi?id=20133
Issue ID: 20133
Summary: [REG2.084.0] Bogus slice assignment in recursive CTFE
call
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: slud...@outerproduct.org
The following snippet yields "Error: array length mismatch assigning `[0..1]`
to `[1..3]`", although no slice assignment should be going on:
---
void bar(ref string text)
{
text = text[1 .. $];
string tcopy = text;
if (tcopy.length > 0)
bar(tcopy);
}
enum test = {
string input = "foo";
bar(input);
return input;
} ();
---
Works as expected up to DMD 2.083.1.
--
[Issue 20116] Wrong delegate type when taking address of inout member function
https://issues.dlang.org/show_bug.cgi?id=20116
Simen Kjaeraas changed:
What|Removed |Added
CC||simen.kja...@gmail.com
Summary|Cannot return inout return |Wrong delegate type when
|value from delegate |taking address of inout
||member function
--- Comment #2 from Simen Kjaeraas ---
I've updated the description to give a better description of what's actually
wrong here.
The actual issue is what typeof() returns - it needs to reflect the
constancy of c - inout makes no sense on the context of a delegate. IOW, this:
class C {
int[] _arr;
auto fun() inout { return _arr; }
}
static assert(is(typeof(&(new C).fun) == int[]
delegate()));
static assert(is(typeof(&(new const C).fun) == const(int[])
delegate()));
static assert(is(typeof(&(new immutable C).fun) == immutable(int[])
delegate()));
should compile.
--
[Issue 20132] New: segfault on fiber.call() in release mode
https://issues.dlang.org/show_bug.cgi?id=20132 Issue ID: 20132 Summary: segfault on fiber.call() in release mode Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: zor...@gmail.com dmd 2.078.1, Manjaro/Arch x86_64. dub 1.16.0, ldc 1.16.0. When calling a specific Fiber in dub's release mode, the program segfaults. It works in debug mode, and binaries compiled with ldc are not affected in either mode. It does not happen on Windows, dmd 2.078.0. > git clone https://github.com/zorael/tests -b fibersegfault > cd tests > dub build -b release-debug > gdb --ex 'run' --ex 'bt' ./fibersegfault I reduced it as much as I could, and the resulting source is a brittle mess. Literally changing anything more in it, like removing or reordering function calls, makes the segfault go away. It's only good for reproducing the segfault and debugging, not for reasoning about. > Program received signal SIGSEGV, Segmentation fault. > 0x555a355b in > _D8kameloso7plugins4help13onCommandHelpFCQBnQBhQBc10HelpPluginSQCj3irc4defs8IRCEventZ2dgMFZv > (__capture=0x0) at source/kameloso/plugins/help.d:15 > 15 void dg() > #0 0x555a355b in > _D8kameloso7plugins4help13onCommandHelpFCQBnQBhQBc10HelpPluginSQCj3irc4defs8IRCEventZ2dgMFZv > (__capture=0x0) at source/kameloso/plugins/help.d:15 > #1 0x77d7936c in core.thread.Fiber.run() () from > /usr/lib/libphobos2.so.0.87 > #2 0x77d78733 in fiber_entryPoint () from /usr/lib/libphobos2.so.0.87 > #3 0x in ?? () > Backtrace stopped: Cannot access memory at address 0x77fce000 __capture=0x0? --
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @WalterBright created dlang/dmd pull request #10312 "fix Issue 20131 - Bad codegen from inline asm LOCK CMPXCHG; possible …" fixing this issue: - fix Issue 20131 - Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing https://github.com/dlang/dmd/pull/10312 --
[Issue 1324] __FILE__ in mixin template expand to the definition, not the instantiation
https://issues.dlang.org/show_bug.cgi?id=1324 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 1479] mixin error across two module
https://issues.dlang.org/show_bug.cgi?id=1479
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #2 from RazvanN ---
This bug is invalid.
When you instantiate `S2!(tpl) v;` in main (test.d), the symbol tpl is visible,
so there's no problem. Now when S2 needs to be instantiated you instantiate S1
with the alias symbol t which points to tpl. This is fine also, but when you
instantiate S1, you mixin the code that is contained by the tpl template which
is
`alias S2!(tpl) tt;`, so your S1 becomes:
struct S1
{
alias S2!tpl tt;
}
but in the file test1.d there is no tpl symbol, therefore you end up with the
correct issued error. To fix this you just have to import test.d.
Closing as invalid.
--
[Issue 1308] Recursive alias declaration, Error: forward reference to foo
https://issues.dlang.org/show_bug.cgi?id=1308 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #3 from RazvanN --- Currently the error message is: test.d(3): Error: template instance r!r recursive template expansion test.d(8): Error: template instance test.r!(r, r) error instantiating This is the correct behavior because when `alias r!r r` is encountered, the compiler says "r is an alias to something, let's see to what" and then it tries to analyze `r!r`. When it takes the first `r` symbol it tries to see what it is and it sees that r is an alias to the type that it is trying now to evaluate. Closing as invalid. --
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131 --- Comment #2 from Walter Bright --- For the moment, until I fix it, you can use db to insert the exact bytes you need. --
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131
--- Comment #1 from Walter Bright ---
Minimal test case:
bool test() {
asm {
naked;
cmpxchg [RDX], DIL;
}
}
--
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Summary|Bad codegen from inline |Bad codegen from inline asm |asm; possible REX prefix|LOCK CMPXCHG; possible REX |missing |prefix missing --
[Issue 20131] Bad codegen from inline asm LOCK CMPXCHG; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131 Walter Bright changed: What|Removed |Added Keywords||iasm --
[Issue 20131] New: Bad codegen from inline asm; possible REX prefix missing
https://issues.dlang.org/show_bug.cgi?id=20131
Issue ID: 20131
Summary: Bad codegen from inline asm; possible REX prefix
missing
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
Compile and dump using:
> dmd asmtest.d -O -c -m64 && objdump asmtest.o -S
asmtest.d
-
bool cas(byte*, byte*, byte)
{
asm pure nothrow @nogc @trusted
{
naked;
mov AL, [RSI];
lock; cmpxchg [RDX], DIL;
mov DL, AL;
setz AL;
je skip_writeback;
mov [RSI], DL;
skip_writeback:
ret;
}
}
Emits:
Disassembly of section .text._D7asmtest3casFPgQcgZb:
<_D7asmtest3casFPgQcgZb>:
0: 8a 06 mov(%rsi),%al
2: f0 0f b0 3a lock cmpxchg %bh,(%rdx)
6: 88 c2 mov%al,%dl
8: 0f 94 c0sete %al
b: 74 02 je f <_D7asmtest3casFPgQcgZb+0xf>
d: 88 16 mov%dl,(%rsi)
f: c3 retq
Note:
Src: lock; cmpxchg [RDX], DIL;
Output: lock cmpxchg %bh,(%rdx)
DIL turned into %bh. only 4 bytes including LOCK... REX prefix missing maybe?
Blocks https://github.com/dlang/druntime/pull/2735
--
