[Issue 12713] New: std.regex.regex crashes with SEGV, illegal instruction resp. assertion failure with certain bad input
https://issues.dlang.org/show_bug.cgi?id=12713 Issue ID: 12713 Summary: std.regex.regex crashes with SEGV, illegal instruction resp. assertion failure with certain bad input Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: yxcvbasdfgqwer...@gmx.de Created attachment 1356 -- https://issues.dlang.org/attachment.cgi?id=1356action=edit Source code for test case The bad regular expression [[a-z]([a-z]|(([[a-z]))) seems to run an unexpected execution path during regular expression compilation which ended up in a segmentation fault (if compiled with -release) or an assertion failure (if not). Verified with dmd 2.065 and ldc2-0.12-1 (the latter causes an 'illegal instruction' crash if compiled with -release). Instead of crashing, the bad expression should be rejected with a proper exception like wrong character class (as for other syntactically wrong expressions). Note: the terms [[a-z] were intended to be [\\[a-z]. --
[Issue 12625] implicit slicing of RValue static array should be illegal
https://issues.dlang.org/show_bug.cgi?id=12625 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com --- Why just make the implicit slice illegal? Shouldn't it just be illegal to slice it at all, since it's guaranteed to be wrong? --
[Issue 12714] New: .offsetof problems in structs with alias this
https://issues.dlang.org/show_bug.cgi?id=12714
Issue ID: 12714
Summary: .offsetof problems in structs with alias this
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
This issue is currently an enhancement request, but I think it's borderline a
bug.
This documentation page:
http://dlang.org/struct.html
Gives a definition of the .offsetof field:
.offsetof Offset in bytes of field from beginning of struct
But in presence of structs with alias this .offsetof has problems:
A comment from Artur Skawina:
if the object does not contain the requested member, but implicitly converts
to another one that does have such field then the expression compiles, but
yields a bogus value.
Example code:
struct Foo {
int f1, f2;
}
struct Bar {
int b1, b2, b3, b4;
Foo x;
alias x this;
}
void main() {
Bar b;
assert(cast(void*)b.f2 - cast(void*)b == 20);
static assert(Bar.x.offsetof == 16);
static assert(Bar.f2.offsetof == 4); // ***
}
I think this is a little trap for D programmers.
I expect Bar.f2.offsetof to return 20 (or not to compile).
In a struct without alias this this situation is more clear:
struct Foo {
int f1, f2;
}
struct Bar {
int b1, b2, b3, b4;
Foo x;
}
void main() {
Bar b;
assert(cast(void*)b.x.f2 - cast(void*)b == 20);
static assert(Bar.x.offsetof == 16);
static assert(Bar.x.f2.offsetof == 4);
}
Now Bar.f2.offsetof doesn't compile, and Bar.x.f2.offsetof is 4 because
it's the offset of the field f2 relative to the start of the struct instance x.
--
[Issue 12625] implicit slicing of RValue static array should be illegal
https://issues.dlang.org/show_bug.cgi?id=12625
--- Comment #2 from monarchdo...@gmail.com ---
(In reply to Jonathan M Davis from comment #1)
Why just make the implicit slice illegal? Shouldn't it just be illegal to
slice it at all, since it's guaranteed to be wrong?
I thought about it some more, and there *are* case where you can slice an
rvalue static array, provided you've used it by the end of the expression.
EG:
//
int sum(int[] i)
{
return reduce!a+b(i);
}
void main()
{
enum int[3] ints = [1, 2, 3];
auto s = sum(ints);
}
//
Here, ints is an rvalue static array, and slicing it is legit.
So it appears my initial description of the problem is no accurate. There are
times where you can slice an rvalue array.
Not sure where to take this now.
- Do we say slicing an Rvalue static array is dangerous, and deprecated,
please do it explicitly?
- Do we find some way to detect *only* the rvalue static array to dynamic
array assignment case?
- Give up?
--
[Issue 12439] Can't access to property call result if the call is in parantheses
https://issues.dlang.org/show_bug.cgi?id=12439 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com --- Issue 12688 is a duplicate of this one but as it's already fixed mark this one as a duplicate. *** This issue has been marked as a duplicate of issue 12688 *** --
[Issue 12688] Strange error if function call is in parentheses
https://issues.dlang.org/show_bug.cgi?id=12688 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com --- *** Issue 12439 has been marked as a duplicate of this issue. *** --
[Issue 12715] New: _compare_fp_t/qsort/bsearch C functions should be nothrow
https://issues.dlang.org/show_bug.cgi?id=12715 Issue ID: 12715 Summary: _compare_fp_t/qsort/bsearch C functions should be nothrow Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: verylonglogin@gmail.com It's a bad idea to throw exceptions across language boundaries as there is no guarantee a C standard library doesn't use its own exception handler for some reason. So `_compare_fp_t` should be `nothrow`. Causing pull: https://github.com/D-Programming-Language/druntime/pull/779 --
[Issue 12625] implicit slicing of RValue static array should be illegal
https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com --- Well, per issue# 8838, we need to make slicing a static array - implicit or otherwise - @system. As it stands, that's a huge hole in @safe. So, that affects this on some level. Regardless of whether implicit slicing takes place, I think that if there are any situations where we can statically know that slicing a static array not only unsafe, but it's guaranteed to be wrong, we should make that an error. There's no reason to allow it. I don't know how easy it will be to enumerate those cases and make them errors, but at minimum, as we find them, we should make them errors. I am 100% convinced that it was a huge mistake to make it so that static arrays are ever implicitly sliced, so I would be very much in favor of deprecating that and move towards removing it from the language, but it would break a lot of code. I think that it's at least similar to the breakage caused by removing implicit fallthrough in that it's highly bug-prone and as such is worth the breakage, but I also don't think that it's wrong in anywhere near as many cases as implicit fallthrough is, so the gain isn't as great. It's also probably far more prevalent in code than switch statements are, so it's likely to be a hard sell. A number of people have already balked at the idea of making slicing static arrays @system even though it's a fact that that has to happen, or we have a whole in @safe - there's no way around that (at best, we _might_ be able to make it @safe in a few cases where scope was used - if scope were fully implemented, which it's not). So, I'd expect a lot of folks to balk at this as well. But I'm convinced that it would be worth it. The question is whether enough people (and in particular, Walter and Andrei) can be convinced of that as well. But I definitely don't think that we should give up on this in that any case where we know that it's guaranteed to be wrong, it should be an error. There's no reason to allow it aside from the fact that we simply missed that particular case (which should then be fixed when we find it). --
[Issue 12625] implicit slicing of RValue static array should be illegal
https://issues.dlang.org/show_bug.cgi?id=12625 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc --- (In reply to monarchdodra from comment #2) - Do we find some way to detect *only* the rvalue static array to dynamic array assignment case? - Give up? Those seem two options. The first introduces a special case. --
[Issue 12705] @system is missing when using getFunctionAttributes on a typeof(function)
https://issues.dlang.org/show_bug.cgi?id=12705 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3533 --
[Issue 12716] New: Improve error message : interface function is not implemented
https://issues.dlang.org/show_bug.cgi?id=12716 Issue ID: 12716 Summary: Improve error message : interface function is not implemented Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: flamaros.xav...@gmail.com I got this error : interface function 'void setParameter(string name, ParameterType type, void* values)' is not implemented I took a few time to figure out what it was. The issue came from multiple definition of enum ParameterType which was in both module (one with the interface and one with the implementation class). I think the error message isn't enough explicit and have to point the existence of multiple definitions of parameters type, it's just like an overloading that isn't allowed. If the message was written like the following form it may be easier to fix it : overloading interface function 'void setParameter(string name, interfaceModuleName.ParameterType type, void* values)' is not allowed. overloads : void setParameter(string name, classModuleName.ParameterType type, void* values) ... --
[Issue 12705] @system is missing when using getFunctionAttributes on a typeof(function)
https://issues.dlang.org/show_bug.cgi?id=12705 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/328b5e51df3e901cff4c8006c837d72a37d00464 Fix Issue 12705 and Fixup Pull 3501 - Default trust implies @system, and typeof(func) should extract proper function attributes. https://github.com/D-Programming-Language/dmd/commit/e1e28ec7ed869b15b065673ca774fe53f2f19d42 Merge pull request #3533 from AndrejMitrovic/FixupAttribs Fix Issue 12705 and Fixup Pull 3501 - Fix @system and missing attributes when typeof(func) is used --
[Issue 3467] Non-int integral template parameters not correctly propagated
https://issues.dlang.org/show_bug.cgi?id=3467 k...@redstar.de changed: What|Removed |Added CC||k...@redstar.de --- Comment #14 from k...@redstar.de --- As a side effect, the name mangling is wrong. Lets change the type parameter from uint to ulong. Then the bar function of foo!( 4 ) baz is mangled as _D7bug346712__T3fooVii4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVii4Z3foo but bar function of foo!( 4L ) baz is mangled as _D7bug346712__T3fooVli4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVli4Z3foo In both cases, I would expect _D7bug346712__T3fooVmi4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVmi4Z3foo because the type parameter is ulong. --
[Issue 3467] Non-int integral template parameters not correctly propagated
https://issues.dlang.org/show_bug.cgi?id=3467 --- Comment #15 from David Nadlinger c...@klickverbot.at --- @Kai: Note that this report is marked as D1 only now. You might want to open a new issue for the mangling problem. --
[Issue 12717] New: chm target does not build
https://issues.dlang.org/show_bug.cgi?id=12717 Issue ID: 12717 Summary: chm target does not build Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com $ make -f win32.mak chm chmgen Processing .\32-64-portability.html Downloading https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js to chm/js/jquery.min.js... Warning: Page not found in navigation Processing .\abi.html Processing .\acknowledgements.html Processing .\appendices.html Warning: Page not found in navigation Processing .\arrays.html Processing .\articles.html Warning: Page not found in navigation Processing .\ascii-table.html Processing .\attribute.html Processing .\bugstats.php.html Error while processing line: pThe home of the D issue tracker is: a href=bhttp://issues.dlang.org/b/a/p Error while processing file: .\bugstats.php.html object.Exception@chmgen.d(56): Empty URL 0x0042BDC2 0x004021F1 0x00403F14 0x004332B8 0x0043328B 0x004331A4 0x00427C0B 0x751F3677 in BaseThreadInitThunk 0x77329D72 in __RtlUserThreadStart 0x77329D45 in _RtlUserThreadStart --- errorlevel 1 --
[Issue 12717] chm target does not build
https://issues.dlang.org/show_bug.cgi?id=12717 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --
[Issue 12717] chm target does not build
https://issues.dlang.org/show_bug.cgi?id=12717 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- (In reply to Andrej Mitrovic from comment #0) Error while processing line: pThe home of the D issue tracker is: a href=bhttp://issues.dlang.org/b/a/p The irony here is that I've introduced that line, so I probably broke the CHM target. But what exactly is wrong with the page so I can fix it? --
[Issue 12718] New: Allow use invariant without parentheses or improve error message
https://issues.dlang.org/show_bug.cgi?id=12718
Issue ID: 12718
Summary: Allow use invariant without parentheses or improve
error message
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
class C {
invariant {}
}
Error: use 'immutable' instead of 'invariant'
I think invariants should be allowed without parentheses or error message
should say about it.
--
[Issue 12719] New: struct.c:705: virtual void StructDeclaration::semantic(Scope*): Assertion `parent parent == sc-parent' failed.
https://issues.dlang.org/show_bug.cgi?id=12719
Issue ID: 12719
Summary: struct.c:705: virtual void
StructDeclaration::semantic(Scope*): Assertion `parent
parent == sc-parent' failed.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: nilsboss...@googlemail.com
Works with 2.065.
---
cat test.d code
struct A
{
B!int b();
}
struct B(T)
{
A a;
void m()
{
auto v = B!T.init;
}
}
code
dmd -c test.d
---
dmd: struct.c:705: virtual void StructDeclaration::semantic(Scope*): Assertion
`parent parent == sc-parent' failed.
Aborted (core dumped)
---
--
[Issue 12717] chm target does not build
https://issues.dlang.org/show_bug.cgi?id=12717 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- Read the error message? a href= That doesn't look right. --
[Issue 12717] chm target does not build
https://issues.dlang.org/show_bug.cgi?id=12717 --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com --- $(LINK2, $(B http://issues.dlang.org)) I think you're supposed to put an URL before the comma. --
[Issue 12706] ddoc: __dollar should not appear in the documentation
https://issues.dlang.org/show_bug.cgi?id=12706 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b5a551ab414da9bec35c49f11b043672be40bd85 Fix Issue 12706 - __dollar should be emitted as a '$' symbol in ddoc output. https://github.com/D-Programming-Language/dmd/commit/540fe4121d3a9b0a2df353ae0035fb5a5d27420b Merge pull request #3529 from AndrejMitrovic/Fix12706 Issue 12706 - __dollar should be emitted as a '$' symbol in ddoc output. --
[Issue 5700] Allow dup in nothrow functions
https://issues.dlang.org/show_bug.cgi?id=5700 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |WORKSFORME --- Comment #7 from Walter Bright bugzi...@digitalmars.com --- This is working in 2.066 head. --
[Issue 12720] New: Non-int integral template parameters not mangled correctly
https://issues.dlang.org/show_bug.cgi?id=12720
Issue ID: 12720
Summary: Non-int integral template parameters not mangled
correctly
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k...@redstar.de
This is a followup of fixed issue 3467. The name mangling is still wrong.
struct foo( ulong n ) {
foo!( n ) bar( ) {
typeof( return ) result;
return result;
}
}
void main( ) {
foo!( 4 ) baz;
baz = baz.bar;// FAIL
}
The bar function of
foo!( 4 ) baz
is mangled as
_D7bug346712__T3fooVii4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVii4Z3foo
but bar function of
foo!( 4L ) baz
is mangled as
_D7bug346712__T3fooVli4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVli4Z3foo
In both cases, I would expect
_D7bug346712__T3fooVmi4Z3foo3barMFNaNbNiNfZS7bug346712__T3fooVmi4Z3foo
because the type parameter is ulong.
There is a partial fix in the source (template.c, around line 7249) but this
does not compile.
--
