[Issue 19051] Undefined functions Set/GetWindowLongPtr in mingw libs
https://issues.dlang.org/show_bug.cgi?id=19051 Rainer Schuetze changed: What|Removed |Added Keywords||pull CC||r.sagita...@gmx.de --- Comment #4 from Rainer Schuetze --- https://github.com/dlang/installer/pull/332 Please try the libraries from: https://ci.appveyor.com/project/4wil/installer/build/1.0.79/artifacts --
[Issue 19061] Specs for contracts don't include the changes brought by DIP 1009
https://issues.dlang.org/show_bug.cgi?id=19061 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from Seb --- It has been stuck in the queue for a while to a problem with the docs generation: https://github.com/dlang/dlang.org/pull/2339 --
[Issue 19063] New: Delete useless aliases in astcodegen.d once all host compilers use 2.079.1 or later
https://issues.dlang.org/show_bug.cgi?id=19063 Issue ID: 19063 Summary: Delete useless aliases in astcodegen.d once all host compilers use 2.079.1 or later Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greeen...@gmail.com The aliases were present to workaround a compiler bug which was fixed by : #7668 but the update couldn't be done because the bootstrapping version of the compiler did not benefit from the fix. Not all bootstrapping compiler have been bumped to 2.079 and as soon as there's a stable GDC release that includes this fix we can remove the aliases. See also: https://github.com/dlang/dmd/pull/8445 --
[Issue 19036] .tupleof order guarantee
https://issues.dlang.org/show_bug.cgi?id=19036 --- Comment #7 from Guillaume Lathoud --- (In reply to Jacob Carlborg from comment #6) > You can concatenate a tuple of types using std.typecons.AliasSeq. That would > be used like this: > > alias a = AliasSeq!(typeof(BaseClass.tupleof), typeof(ChildClass.tupleof)); > > It seems it's not possible to concatenate without using "typeof". Thanks! --
[Issue 19059] Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059 Mathias LANG changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #3 from Mathias LANG --- @ag0aep0g: AFAICS, solution 3 is what's currently implemented. --
[Issue 19061] Specs for contracts don't include the changes brought by DIP 1009
https://issues.dlang.org/show_bug.cgi?id=19061 Basile B. changed: What|Removed |Added Depends on||19062 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=19062 [Issue 19062] Accepted grammar for DIP 1009 introduces the `InExpression` which already exists --
[Issue 19062] Accepted grammar for DIP 1009 introduces the `InExpression` which already exists
https://issues.dlang.org/show_bug.cgi?id=19062 Basile B. changed: What|Removed |Added Blocks||19061 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=19061 [Issue 19061] Specs for contracts don't include the changes brought by DIP 1009 --
[Issue 19062] Accepted grammar for DIP 1009 introduces the `InExpression` which already exists
https://issues.dlang.org/show_bug.cgi?id=19062 Basile B. changed: What|Removed |Added CC|reachz...@gmail.com | --- Comment #1 from Basile B. --- pull: https://github.com/dlang/DIPs/pull/128/files --
[Issue 19062] Accepted grammar for DIP 1009 introduces the `InExpression` which already exists
https://issues.dlang.org/show_bug.cgi?id=19062 Basile B. changed: What|Removed |Added CC||reachz...@gmail.com --
[Issue 19059] Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #2 from Mike Franklin --- If octal literals are gone, I vote for (2). I don't think we should be too draconian about such C compatibility rules, especially to accommodate octals, which are even an oddity in C. --
[Issue 19060] [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #3 from ag0aep6g --- As far as I can see, the deprecation is correct. You can't get an alias of an instance field. The alias was to `S.x` the whole time. You're just being forced to spell it out now. --
[Issue 19062] New: Accepted grammar for DIP 1009 introduces the `InExpression` which already exists
https://issues.dlang.org/show_bug.cgi?id=19062 Issue ID: 19062 Summary: Accepted grammar for DIP 1009 introduces the `InExpression` which already exists Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: blocker Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com https://dlang.org/spec/grammar.html#InExpression https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md#grammar --
[Issue 19059] Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from ag0aep6g --- Per the spec [1], `01` through `09` are all invalid since octal literals are gone. They all have obvious values, though. Which is probably why they've been kept around. I see three ways forward: 1) Outlaw `01` through `09`. This would break existing code. 2) Let all literals that start with zero be decimals instead of octals. `01` would be 1, `08` would be 8, `000123` would be 123. This would break the rule that C code should either behave the same or fail compilation in D. 3) Allow only `01` through `09` as decimal literals. Not elegant, but it might be the best option. [1] https://dlang.org/spec/lex.html#DecimalInteger --
[Issue 19061] New: Specs for contracts don't include the changes brought by DIP 1009
https://issues.dlang.org/show_bug.cgi?id=19061 Issue ID: 19061 Summary: Specs for contracts don't include the changes brought by DIP 1009 Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com https://dlang.org/changelog/2.081.0.html#expression-based_contract_syntax https://dlang.org/spec/grammar.html#FunctionContracts --
[Issue 19060] [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060
Richard Cattermole changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #2 from Richard Cattermole ---
Okay looks like I was wrong.
Removing the class it would be equivalent at the module level to:
---
module self;
bool x;
template Foo() {
alias y = self.x;
}
alias Bar = Foo!();
---
--
[Issue 19060] [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060 --- Comment #1 from Richard Cattermole --- This was changed on purpose. https://dlang.org/changelog/2.081.0.html#deprecate_this_super_as_types --
[Issue 19060] [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060 Richard Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |INVALID --
[Issue 19060] [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 19060] New: [REG2.081] Incorrect "Using this as a type is deprecated" error
https://issues.dlang.org/show_bug.cgi?id=19060
Issue ID: 19060
Summary: [REG2.081] Incorrect "Using this as a type is
deprecated" error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
Testcase:
```
struct S {
bool x;
public template yoyo() {
alias yoyo = this.x; // line 5
}
public ref foo() {
return yoyo!();
}
}
```
Works correctly with dmd < 2.081, fails (incorrect deprecation) with 2.081:
❯ dmd testcase.d -de
testcase.d(5): Deprecation: Using this as a type is deprecated. Use
typeof(this) instead
--
[Issue 18868] Separate compilation generates two static this functions, runs it twice
https://issues.dlang.org/show_bug.cgi?id=18868 --- Comment #6 from Atila Neves --- I forgot to mention that the issue here is the same issue as before with the unittest names - counters can't and won't work, because the number will vary depending on how the compiler is invoked. --
[Issue 18868] Separate compilation generates two static this functions, runs it twice
https://issues.dlang.org/show_bug.cgi?id=18868 Atila Neves changed: What|Removed |Added CC||atila.ne...@gmail.com --- Comment #5 from Atila Neves --- The fix for this issue introduces a regression and breaks usage of __traits(getUnitTests) and separate compilation. Issue here: https://issues.dlang.org/show_bug.cgi?id=19058 --
[Issue 19059] New: Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059
Issue ID: 19059
Summary: Invalid integer literal 08 and 09 allowed
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: trivial
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kub...@gmail.com
---
void main()
{
assert(08 == 8); // can compile and run.
assert(09 == 9);
}
--
[Issue 19058] New: __traits(getUnitTests) stops working with separate compilation in dmd 2.081.0
https://issues.dlang.org/show_bug.cgi?id=19058 Issue ID: 19058 Summary: __traits(getUnitTests) stops working with separate compilation in dmd 2.081.0 Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: atila.ne...@gmail.com This is a regression of 16995 caused by: commit 849155631cba3017566d3160cf15cb40584abf10 Author: Johan Engelen Date: Thu May 17 00:25:56 2018 +0200 fix Issue 18868 - nondeterministic static ctor/dtor Instead of using a counter to create unique static ctor and dtor function identifiers, use the deterministic line+column location that is also used for unittests. The further disambiguate mixin instantiations on the exact same location, use a local counter. The reason the existing test for 16995 didn't break is because it only uses one module with unittests, and there must be two different modules with unittests on the same line:column to trigger the regression. --
[Issue 19057] 2.079 changelog variadic template and default arguments
https://issues.dlang.org/show_bug.cgi?id=19057 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 19057] New: 2.079 changelog variadic template and default arguments
https://issues.dlang.org/show_bug.cgi?id=19057
Issue ID: 19057
Summary: 2.079 changelog variadic template and default
arguments
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
The changelog of 2.079 says:
"
3. Function parameters with default values are now allowed after variadic
template parameters
Function parameters with default values are now allowed after variadic template
parameters and when IFTI is used, always take their default values.
...
"
However, parameters with default values were already allowed after variadic
template parameters. And the 2.079-change of behavior results in compile errors
(in the best case), but may also lead to bad runtime behavior of previously
working code. I hope the change was made knowingly that it was a semantic
change, instead of an addition to the semantics...
Simple test case:
```
import std.stdio;
void bar(Args...)(Args _args, int timeout = 0) {
pragma(msg, typeof(_args));
writeln(_args, timeout);
}
void main() {
bar("a", "b", 2); // used to print "ab2", but since 2.079 prints "ab20"
}
```
Semantic changes like this need to be very clearly marked in the changelog.
Updating the compiler on a commercial codebase is already enough of an
adventure, no need to add extra uncertainties.
Please fix the changelog.
Thanks,
Johan
--
[Issue 19036] .tupleof order guarantee
https://issues.dlang.org/show_bug.cgi?id=19036 --- Comment #6 from Jacob Carlborg --- (In reply to Guillaume Lathoud from comment #5) > One the side: is there an easy way to concatenate two expression sequences? > I am thinking of something like BaseClass.tupleof ~ ChildClass.tupleof You can concatenate a tuple of types using std.typecons.AliasSeq. That would be used like this: alias a = AliasSeq!(typeof(BaseClass.tupleof), typeof(ChildClass.tupleof)); It seems it's not possible to concatenate without using "typeof". --
[Issue 19056] New: UDAs can be added to imports but not retrieved
https://issues.dlang.org/show_bug.cgi?id=19056 Issue ID: 19056 Summary: UDAs can be added to imports but not retrieved Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: elpenguin...@gmail.com It is currently legal to attach UDAs to imports, but there's no way to retrieve them. ie: ``` enum X; @X import y = std.stdio; pragma(msg, __traits(getAttributes, y)); ``` I would expect the compiler to either print the attributes or emit an error, not print an empty tuple. --
[Issue 18743] ConditionalExpression and AssignExpression should require parentheses
https://issues.dlang.org/show_bug.cgi?id=18743 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18743] ConditionalExpression and AssignExpression should require parentheses
https://issues.dlang.org/show_bug.cgi?id=18743 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/0cfc780539838d8c6294174a0587fd5b5c33de94 Fix Issue 18743 - ConditionalExpression and AssignExpression should require parens https://github.com/dlang/dmd/commit/0ed6065c6565e69aa9291887b89daf568db230de Merge pull request #8237 from ntrel/cond-parens Fix Issue 18743 - ConditionalExpression with AssignExpression should require parens merged-on-behalf-of: Razvan Nitu --
[Issue 19036] .tupleof order guarantee
https://issues.dlang.org/show_bug.cgi?id=19036 --- Comment #5 from Guillaume Lathoud --- (In reply to Jacob Carlborg from comment #4) > To get the fields of the base class you can upcast it and then use .tupleof. > That is: (cast(Base) subclassObject).tupleof. You can also use some traits > in Phobos to get the base class from a subclass. Thanks! Now I see that the official .tupleof example *does* rely on the proper order: https://dlang.org/spec/class.html#class_properties foo.tupleof[0] = 1; // set foo.x to 1 foo.tupleof[1] = 2; // set foo.y to 2 ...so I guess this guarantee should be made explicit. That would be the topic of the issue here. One the side: is there an easy way to concatenate two expression sequences? I am thinking of something like BaseClass.tupleof ~ ChildClass.tupleof --
[Issue 19036] .tupleof order guarantee
https://issues.dlang.org/show_bug.cgi?id=19036 --- Comment #4 from Jacob Carlborg --- (In reply to Guillaume Lathoud from comment #3) > In another use case there is a class hierarchy, I > also need the fields of the base class, which .tupleof does not provide, so > I am not sure anymore how useful the present issue would be. To get the fields of the base class you can upcast it and then use .tupleof. That is: (cast(Base) subclassObject).tupleof. You can also use some traits in Phobos to get the base class from a subclass. --
[Issue 19053] debug should escape @safe
https://issues.dlang.org/show_bug.cgi?id=19053 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19053] debug should escape @safe
https://issues.dlang.org/show_bug.cgi?id=19053 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/aae8f5610f7843b272e2aa21119d99c4f30d1036 Fix Issue 19053 - debug should escape @safe https://github.com/dlang/dmd/commit/582faa48982916f9597d1a1989a4d174c7f8a43d Merge pull request #8450 from wilzbach/fix-18407-safe Fix Issue 19053 - debug should escape @safe merged-on-behalf-of: Razvan Nitu --
[Issue 19055] New: [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 Issue ID: 19055 Summary: [404 Not Found] std.digest.digest Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW Severity: trivial Priority: P3 Component: dlang.org Assignee: nob...@puremagic.com Reporter: iamthewilsona...@hotmail.com Library overview -> std -> digest ->digest 404's. --
[Issue 19031] [REG 2.080.0] assert failure when subclassing C++ class with D class
https://issues.dlang.org/show_bug.cgi?id=19031 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- Try making class Foo extern(C++) and add "alias visit = SemanticTimeTransitiveVisitor.visit" in the class body. This should get rid of the compile errors (don't know about the assert though). --
[Issue 19054] alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054 --- Comment #2 from Tomer Filiba (weka) --- i mentioned RCX because of https://github.com/dlang/druntime/blob/9a8edfb48e4842180c706ee26ebd8edb10be53f4/src/rt/alloca.d#L230 --
[Issue 19054] alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054 Tomer Filiba (weka) changed: What|Removed |Added CC||e...@weka.io --
[Issue 19054] alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054 Tomer Filiba (weka) changed: What|Removed |Added CC||m...@weka.io, to...@weka.io --
[Issue 19054] alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054 --- Comment #1 from Tomer Filiba (weka) --- DMD64 D Compiler v2.080.0 --
[Issue 19054] alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054 Tomer Filiba (weka) changed: What|Removed |Added Keywords||industry --
[Issue 19054] New: alloca() crashes with SEGFAULT after an exception
https://issues.dlang.org/show_bug.cgi?id=19054
Issue ID: 19054
Summary: alloca() crashes with SEGFAULT after an exception
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: to...@weka.io
it seems RCX is corrupt after the exception (which has finished handling and
all), which AFAICT should hold the size of the temp stack size
```
import core.stdc.stdlib: alloca;
void main() {
void* p1 = alloca(10);
writeln(p1);
try {
throw new Exception("foo");
}
catch (Exception ex) {
writeln(ex.msg);
}
void* p2 = alloca(10); // <<< SEGFAULT on 0x7000
//rax0x7fffd7b0140737488345008
//rbx0x33
//rcx0x1cf82305843009213693176
//rdx0x7fffd870140737488345200
//rsi0x7000140737488351232
//rdi0x7fffeff0140737488351216
//rbp0x7fffd9000x7fffd900
//rsp0x7fffd8480x7fffd848
writeln(p2);
}
```
--
