[Issue 15849] change in std.ui test leads to magic linking error for d_do_test
https://issues.dlang.org/show_bug.cgi?id=15849 greenify changed: What|Removed |Added CC||greeen...@gmail.com --
[Issue 4142] Missing tags in compiler/druntime/phobos git repositories
https://issues.dlang.org/show_bug.cgi?id=4142 greenify changed: What|Removed |Added Status|REOPENED|RESOLVED CC||greeen...@gmail.com Resolution|--- |FIXED --- Comment #5 from greenify --- AFAIK phobos and dmd now use git tags to annotate releases. closing. --
[Issue 11274] Use a CDN for dlang.org
https://issues.dlang.org/show_bug.cgi?id=11274 greenify changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from greenify --- I can only recommend CloudFare and for such an high-traffic site like dlang.org to use a CDN. I had good experiences with CloudFare in the past. Bumping this as it can be done in ten minutes and adds a huge value to visitors. --
[Issue 15849] New: change in std.ui test leads to magic linking error for d_do_test
https://issues.dlang.org/show_bug.cgi?id=15849
Issue ID: 15849
Summary: change in std.ui test leads to magic linking error for
d_do_test
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: greeen...@gmail.com
How to reproduce?
```
git remote add greenify git://github.com:greenify/phobos.git
git fetch greenify
git checkout --track greenify/examples_to_unittest5
```
Now rebuild Phobos and run in dmd
```
make -f posix.mak clean && make -f posix.mak auto-tester-build && make -f
posix.mak auto-tester-test
```
It will result a long error (see below).
The line that toggles the error is
```
assert(set.byInterval.equal([tuple('A','E'), tuple('a','e')]));
```
It is in a unittest, so it shouldn't affect any script.
Running all tests in Phobos works fine.
It is reproducible on all platforms of autotester. See also the regarding PR:
https://github.com/D-Programming-Language/phobos/pull/4049
```
make -C test -f Makefile
make[1]: Entering directory '/home/xsebi/projects/dlang/dmd/test'
Creating output directory: test_results
Building d_do_test tool
OS: linux
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T6ParserTAyaZ6Parser11charsetToIrMFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZv:
error: undefined reference to
'_D3std5regex8internal2ir10getMatcherFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T6ParserTAyaZ6Parser11charsetToIrMFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZv:
error: undefined reference to '_D3std5regex8internal2ir11CharMatcher6__initZ'
d_do_test.o:d_do_test.d:_D45TypeInfo_S3std5regex8internal2ir11CharMatcher6__initZ:
error: undefined reference to
'_D3std5regex8internal2ir11CharMatcher9__xtoHashFNbNeKxS3std5regex8internal2ir11CharMatcherZm'
d_do_test.o:d_do_test.d:_D45TypeInfo_S3std5regex8internal2ir11CharMatcher6__initZ:
error: undefined reference to
'_D3std5regex8internal2ir11CharMatcher11__xopEqualsFKxS3std5regex8internal2ir11CharMatcherKxS3std5regex8internal2ir11CharMatcherZb'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T8optimizeTaZ8optimizeFKS3std5regex8internal2ir12__T5RegexTaZ5RegexZv:
error: undefined reference to
'_D3std5regex8internal2ir8BitTable6__ctorMFNcS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZS3std5regex8internal2ir8BitTable'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8intern
[Issue 15179] Local imports cause outer imports to be excluded from overload set
https://issues.dlang.org/show_bug.cgi?id=15179 --- Comment #8 from Jesse Phillips --- (In reply to Steven Schveighoffer from comment #7) > (In reply to Jesse Phillips from comment #6) > > That doesn't solve the highjacking, Walter has made a big point about D's > > anti-highjacking feature. > > Yes, it does. Selective imports override any non-selective import because > it's aliased into the local namespace. It does not. Since I wrote code where selective imports was not necessary, an update to a second library being used hijacked my call and the compiler gave no warning. That is the hijack problem, the fact that I can modify my code to use the desired function is not relevant to how the compiler is supposed to help prevent hijacking: http://dlang.org/hijack.html --
[Issue 15839] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #6 from Martin Nowak --- (In reply to Kenji Hara from comment #4) > Note that, compiler cannot determine whether the start() makes a closure > environment or not at the place where 'this.outer' is used. Because of that, > the .outer property should have void* type, to be consistent with the > lexical scope nesting. But this.outer always refers to the enclosing function even if no closure is required, right? A this.outer that is typed as void* and either refers to an enclosing function or an enclosing class would be highly confusing. --
[Issue 15500] default construction disabled for struct constructor with default arguments
https://issues.dlang.org/show_bug.cgi?id=15500 Martin Nowak changed: What|Removed |Added CC||wiko...@gmail.com --- Comment #8 from Martin Nowak --- *** Issue 15551 has been marked as a duplicate of this issue. *** --
[Issue 15551] default construction disabled with default arguments
https://issues.dlang.org/show_bug.cgi?id=15551 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |DUPLICATE --- Comment #1 from Martin Nowak --- *** This issue has been marked as a duplicate of issue 15500 *** --
[Issue 15845] Windows console cannot read properly UTF-8 lines
https://issues.dlang.org/show_bug.cgi?id=15845
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #2 from ag0ae...@gmail.com ---
For -m32 (DIGITAL_MARS_STDIO) it seems to come down to this (with `chcp 65001`
in the console):
import std.stdio;
void main()
{
FILE* fps = core.stdc.stdio.stdin;
FLOCK(fps);
scope(exit) FUNLOCK(fps);
auto fp = cast(_iobuf*)fps;
assert(!(__fhnd_info[fp._file] & FHND_WCHAR)); /* passes; no wide
characters */
assert(!(fp._flag & _IOTRAN)); /* passes; no translated mode */
int c = FGETC(fp);
assert(c != -1); /* passes with 'a'; fails with 'ä' */
}
That is, Digital Mars's FGETC (_fgetc_nlock) returns -1 for non-ASCII
characters.
The issue does not manifest with a pipe: `echo ä | test` works.
--
[Issue 15848] out doesn't call opAssign()
https://issues.dlang.org/show_bug.cgi?id=15848 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #2 from ag0ae...@gmail.com --- (In reply to lasssafin from comment #1) > I'm not sure I follow: Why should opAssign be called? Either a new Test is constructed by foo, but then the destructor should be called on the old Test. Or the existing Test is used, but then opAssign should be called instead of just writing Test.init over the old value. I think the spec [1] is rather clear about which one should happen: > out parameter is initialized upon function entry with the default value for > its type So I think the destructor should be called. 1 http://dlang.org/spec/function.html#parameters --
[Issue 15847] It is not an error to call opAssign on an uninitialized object
https://issues.dlang.org/show_bug.cgi?id=15847 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #3 from ag0ae...@gmail.com --- (In reply to monkeyworks12 from comment #2) > No, we definitely don't want that. My point is that it is never valid to > have opAssign called on a void initialized object that has a custom > opAssign. It works for simple value types, but anything with a custom > opAssign cannot allow it. Maybe void initialization should be disabled for > types with custom opAssign. I don't see how void initialization of types with a custom opAssign is bad enough to disallow it. You just have to avoid calling the opAssign during manual initialization, but that's entirely doable. /* ... struct Test as in your code ... */ Test t = void; t.n = int.init; /* manual initialization without calling opAssign */ t = 0; /* no problem */ A generic version (could also use memcpy or similar): Test tinit = Test.init; * cast(void[Test.sizeof]*) &t = * cast(void[Test.sizeof]*) &tinit; This is similar to how `cast(void*) someClassObject` can do something surprising when it calls a custom opCast. But casts and void initialization are dangerous, unsafe features to be used with much care. And a programmer who uses them is expected to be aware of opCast and opAssign. --
[Issue 15848] out doesn't call opAssign()
https://issues.dlang.org/show_bug.cgi?id=15848 lasssa...@gmail.com changed: What|Removed |Added CC||lasssa...@gmail.com --- Comment #1 from lasssa...@gmail.com --- I'm not sure I follow: Why should opAssign be called? --
[Issue 15217] overloaded extern(C) function declarations are allowed
https://issues.dlang.org/show_bug.cgi?id=15217 Johan Engelen changed: What|Removed |Added CC||jbc.enge...@gmail.com --- Comment #1 from Johan Engelen --- "GetMonitorInfoA" is also overloaded in this way in druntime, https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/winuser.d#L4425-L4428 --
[Issue 15847] It is not an error to call opAssign on an uninitialized object
https://issues.dlang.org/show_bug.cgi?id=15847 monkeywork...@hotmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from monkeywork...@hotmail.com --- 'Using void initialization doesn't mean "please turn the first assignment into a construction".' No, we definitely don't want that. My point is that it is never valid to have opAssign called on a void initialized object that has a custom opAssign. It works for simple value types, but anything with a custom opAssign cannot allow it. Maybe void initialization should be disabled for types with custom opAssign. --
[Issue 15847] It is not an error to call opAssign on an uninitialized object
https://issues.dlang.org/show_bug.cgi?id=15847 Marc Schütz changed: What|Removed |Added Status|NEW |RESOLVED CC||schue...@gmx.net Resolution|--- |INVALID --- Comment #1 from Marc Schütz --- Your test cannot work reliably, but... It is not a bug that opAssign() is called here. Using void initialization doesn't mean "please turn the first assignment into a construction". That wouldn't work in the general case. It means "don't initialize this variable, I'll take care of it myself". However, what you wrote on Github - that the assignment operator for the out parameter isn't called - is still true. I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15848 --
[Issue 15848] New: out doesn't call opAssign()
https://issues.dlang.org/show_bug.cgi?id=15848
Issue ID: 15848
Summary: out doesn't call opAssign()
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
import std.stdio;
void foo(out Test x) {
writeln("x.n = ", x.n);
}
struct Test {
int n;
~this() {
writeln("~this()");
}
int opAssign(int val) {
writefln("opAssign(%s)", val);
return n = val + 1;
}
}
void main() {
Test t;
foo(t);
writeln("done");
}
// output:
x.n = 0
done
~this()
Conclusion:
Upon entering foo(), Test.opAssign() is not called. An argument could be made
that `out` shouldn't construct a new struct, not assign an existing one, but in
that case, it would have to call Test.~this(), which doesn't happen either.
--
[Issue 15847] New: It is not an error to call opAssign on an uninitialized object
https://issues.dlang.org/show_bug.cgi?id=15847
Issue ID: 15847
Summary: It is not an error to call opAssign on an
uninitialized object
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
struct Test
{
int n;
int opAssign(int val)
{
assert(n == int.init, "n is in an uninitialized state");
return n = val;
}
}
void main()
{
Test t = void;
//opAssign should not be called here as t is uninitialized
t = 0; //BOOM
}
--
