[Issue 13372] traits parent does not work on eponymous templates
https://issues.dlang.org/show_bug.cgi?id=13372
--- Comment #4 from Mike Franklin ---
(In reply to Basile B. from comment #2)
> =
> import std.meta;
>
> template Parent(T)
> {
> alias Parent = AliasSeq!(__traits(parent, T))[0];
> }
>
> unittest
> {
> class A(T){}
> static assert(A!int.stringof != Parent!(A!int).stringof);
> }
> =
>
> yields: Error: static assert ("A!int" != "A!int") is false
>
>
> the longer form
>
> =
> import std.meta;
>
> template Parent(T)
> {
> alias Parent = AliasSeq!(__traits(parent, T))[0];
> }
>
> unittest
> {
> template B(T){class B{}}
> alias T = B!int;
> static assert(is(T));
> static assert(T.stringof != Parent!T.stringof);
> }
> =
>
> yields: Error: static assert ("B!int" != "B!int") is false
These two tests now pass in v2.078.1
--
[Issue 18312] string concatenation with -betterC fails with linker errors
https://issues.dlang.org/show_bug.cgi?id=18312 Steven Schveighoffer changed: What|Removed |Added Keywords||betterC --- Comment #3 from Steven Schveighoffer --- This is one of those "magic" calls from the compiler to the runtime. I agree it can be replaced with a template, and then the linker error will be replaced with a compile time error (or maybe one can provide a betterC runtime that works without druntime?) The TypeInfo is how the old-time runtime functions communicated the type. There is slow but steady progress to replace these calls with template calls, allowing the runtime more control over what happens. --
[Issue 18312] string concatenation with -betterC fails with linker errors
https://issues.dlang.org/show_bug.cgi?id=18312 --- Comment #2 from Mike Franklin --- > What is the expected result? If TypeInfo is indeed required to perform string concatenation, then the compiler should emit a compile-time error by checking the `global.params.usetypeinfo` flag. This can be implemented very easily today, but I think that this is a symptom of a more systematic problem in D. I'm skeptical that TypeInfo is a necessity for this operation, and ideally TypeInfo should not be required. Removing the dependency on TypeInfo would remove the reference to '_D12TypeInfo_Aya6__initZ'. The runtime hook `_d_arraycatnTx` could probably be replaced with a template, which would result in a compile-time error saying that it can't find/instantiate the template. --
[Issue 18279] rt.util.utf does not properly reserve buffer in toUTF16/toUTF16z
https://issues.dlang.org/show_bug.cgi?id=18279 --- Comment #2 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #1) > PR: https://github.com/dlang/druntime/pull/2065 Already open PR: https://github.com/dlang/druntime/pull/2053 --
[Issue 18315] wrong code for `i > 0`
https://issues.dlang.org/show_bug.cgi?id=18315 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #4 from Martin Nowak --- Check cdcmp https://github.com/dlang/dmd/blob/62e615bf79f49ccd8c1ab45d6c38b956d2895c21/src/dmd/backend/cod4.c#L2066 --
[Issue 18312] string concatenation with -betterC fails with linker errors
https://issues.dlang.org/show_bug.cgi?id=18312 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- What is the expected result? I'm not too familiar with how -betterC works, so I'm not sure whether it should complain that it can't use concatenation, or you expect it to work. How do other attempts to use the runtime fare? --
[Issue 18309] std.process.pipeProcess should warn if the buffer is full
https://issues.dlang.org/show_bug.cgi?id=18309 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- What is the suggestion here? That tryWait should tell you the read buffer is full? Or that there be a mechanism to check for buffer being full? I know that pipes can be unintuitive if you haven't set up your ends properly. There are all kinds of cases where you may have a race condition. The sample above, and the solution you suggest, are both counter-intuitive to me. IMO, the solution is not to worry about the process ending until after you've exhausted the data stream. In any case, I'm inclined to say that we aren't going to solve this problem by adding any warnings. In fact, I'd discourage having any kind of code based on the buffer being full, as your code, if written correctly, should be pretty immune to buffer sizes. Piling on top of that -- the pipe itself is abstracted behind a File, which is *also* buffered. extracting meaningful info about the OS's pipe buffer may be a lost cause. A solution documentation-wise would be to show that pipes are in fact subject to race conditions, and you need to be careful how you code them. --
[Issue 18289] static function and access frame
https://issues.dlang.org/show_bug.cgi?id=18289 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --
[Issue 18279] rt.util.utf does not properly reserve buffer in toUTF16/toUTF16z
https://issues.dlang.org/show_bug.cgi?id=18279 Steven Schveighoffer changed: What|Removed |Added Keywords||pull CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- PR: https://github.com/dlang/druntime/pull/2065 --
[Issue 18324] New: String switch lowering geneartes really long symbol names
https://issues.dlang.org/show_bug.cgi?id=18324 Issue ID: 18324 Summary: String switch lowering geneartes really long symbol names Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@benjamin-thaut.de The following symbol is generated from a string switch during the compilation of phobos: _D6object__T8__switchTyaVxAyaa7_43535436434454VxQwa7_45535435454454VxQBra7_4574632f474d54VxQCna7_4d5354374d4454VxQDja7_50535438504454VxQEfa9_417369612f4164656eVxQFfa9_417369612f42616b75VxQGfa9_417369612f44696c69VxQHfa9_417369612f486f7664VxQIfa9_417369612f4f6d736bVxQJfa9_417369612f4f72616cVxQKfa9_4574632f474d542b31VxQLfa9_4574632f474d542b32VxQMfa9_4574632f474d542b33VxQNfa9_4574632f474d542b34VxQOfa9_4574632f474d542b35VxQPfa9_4574632f474d542b36VxQQfa9_4574632f474d542b37VxQRfa9_4574632f474d542b38VxQSfa9_4574632f474d542b39VxQTfa9_4574632f474d542d31VxQUfa9_4574632f474d542d32VxQVfa9_4574632f474d542d33VxQWfa9_4574632f474d542d34VxQXfa9_4574632f474d542d35VxQYfa9_4574632f474d542d36VxQZfa9_4574632f474d542d37VxQBAfa9_4574632f474d542d38VxQBBga9_4574632f474d542d39VxQBCha10_417369612f416d6d616eVxQBDla10_417369612f4171746175VxQBEpa10_417369612f4368697461VxQBFta10_417369612f4468616b61VxQBGxa10_417369612f4475626169VxQBIba10_417369612f4b6162756cVxQBJfa10_417369612f4d61636175VxQBKja10_417369612f! 5161746172VxQBLna10_417369612f53656f756cVxQBMra10_417369612f546f6b796fVxQBNva10_417369612f546f6d736bVxQBOza10_4574632f474d542b3130VxQBQda10_4574632f474d542b3131VxQBRha10_4574632f474d542b3132VxQBSla10_4574632f474d542d3130VxQBTpa10_4574632f474d542d3131VxQBUta10_4574632f474d542d3132VxQBVxa10_4574632f474d542d3133VxQBXba10_4574632f474d542d3134VxQBYfa11_4166726963612f4a756261VxQBZla11_4166726963612f4c6f6d65VxQCAra11_417369612f416c6d617479VxQCBxa11_417369612f416e61647972VxQCDda11_417369612f4171746f6265VxQCEja11_417369612f426569727574VxQCFpa11_417369612f4272756e6569VxQCGva11_417369612f486562726f6eVxQCIba11_417369612f4b7577616974VxQCJha11_417369612f4d616e696c61VxQCKna11_417369612f4d7573636174VxQCLta11_417369612f526979616468VxQCMza11_417369612f536169676f6eVxQCOfa11_417369612f546169706569VxQCPla11_417369612f54656872616eVxQCQra11_417369612f5572756d7169VxQCRxa11_4575726f70652f4b696576VxQCTda11_4575726f70652f4f736c6fVxQCUja11_4575726f70652f52696761VxQCVpa11_4575726f70652f526f6d65VxQCWva1! 1_496e6469616e2f4d616865VxQCYba12_4166726963612f4163637261VxQCZja12_4166726963612f436169726fVxQDAra12_4166726963612f4365757461VxQDBza12_4166726963612f44616b6172VxQDDha12_4166726963612f4c61676f73VxQDEpa12_4166726963612f54756e6973VxQDFxa12_416d65726963612f4164616bVxQDHfa12_416d65726963612f4c696d61VxQDIna12_416d65726963612f4e6f6d65VxQDJva12_417369612f42616768646164VxQDLda12_417369612f4261687261696eVxQDMla12_417369612f42616e676b6f6bVxQDNta12_417369612f4261726e61756cVxQDPba12_417369612f426973686b656bVxQDQja12_417369612f436f6c6f6d626fVxQDRra12_417369612f49726b7574736bVxQDSza12_417369612f4a616b61727461VxQDUha12_417369612f4b617261636869VxQDVpa12_417369612f4b756368696e67VxQDWxa12_417369612f4d61676164616eVxQDYfa12_417369612f4e69636f736961VxQDZna12_417369612f52616e676f6f6eVxQEAva12_417369612f5462696c697369VxQECda12_417369612f5468696d706875VxQEDla12_417369612f59616b7574736bVxQEEta12_417369612f5965726576616eVxQEGba12_4575726f70652f4d616c7461VxQEHja12_4575726f70652f4d696e736bVxQEIra12_4575726f70652f5061726973VxQEJza12_4575726f70652f536f666961VxQELha12_45757! 26f70652f566164757aVxQEMpa12_496e6469616e2f436f636f73VxQENxa12_506163696669632f41706961VxQEPfa12_506163696669632f46696a69VxQEQna12_506163696669632f4775616dVxQERva12_506163696669632f4e697565VxQETda12_506163696669632f5472756bVxQEUla12_506163696669632f57616b65VxQEVta13_4166726963612f41736d657261VxQEXda13_4166726963612f42616d616b6fVxQEYna13_4166726963612f42616e677569VxQEZxa13_4166726963612f42616e6a756cVxQFBha13_4166726963612f426973736175VxQFCra13_4166726963612f446f75616c61VxQFEba13_4166726963612f486172617265VxQFFla13_4166726963612f4b6967616c69VxQFGva13_4166726963612f4c75616e6461VxQFIfa13_4166726963612f4c7573616b61VxQFJpa13_4166726963612f4d616c61626fVxQFKza13_4166726963612f4d617075746fVxQFMja13_4166726963612f4d6173657275VxQFNta13_4166726963612f4e69616d6579VxQFPda13_416d65726963612f4172756261VxQFQna13_416d65726963612f4261686961VxQFRxa13_416d65726963612f42656c656dVxQFTha13_416d65726963612f426f697365VxQFUra13_416d65726963612f4a756a7579VxQFWba13_416d65726963612f5369746b61VxQFXla13_4! 16d65726963612f5468756c65VxQFYva13_417369612f4173686761626174VxQGAfa13_417369612f43616c6375747461VxQGBpa13_417369612f44616d6173637573VxQGCza13_417369612f44757368616e6265VxQGEja13_417369612f4a61796170757261VxQGFta13_417369612f4b61746d616e6475VxQGHda13_417369612f4b68616e64796761VxQGIna13_417369612f4d616b6173736172VxQGJxa13_417369612f53616b68616c696eVxQGLha13_417369612f5368616e67686169VxQGMra13_417369612f5461736
[Issue 15482] new uuid.d forbids to link statically with other libraries
https://issues.dlang.org/show_bug.cgi?id=15482 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/f9e92a011953bf4fef0e4ef34e898ba14796b93d fix issue 15482 - new uuid.d forbids to link statically with other libraries remove "export extern (C)" from IIDs to not conflict with uuid.lib from the platform SDK https://github.com/dlang/druntime/commit/f2f3f240267376b53f5c72a5a8141139086a3390 Merge pull request #2063 from rainers/issue15482 fix issue 15482 - new uuid.d forbids to link statically with other libs --
[Issue 15482] new uuid.d forbids to link statically with other libraries
https://issues.dlang.org/show_bug.cgi?id=15482 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 18318] std.net.curl.download silently ignores non-2xx http statuses
https://issues.dlang.org/show_bug.cgi?id=18318
Aravinda changed:
What|Removed |Added
CC||hallimanearav...@gmail.com
--- Comment #2 from Aravinda ---
(In reply to Martin Nowak from comment #0)
> cat > bug.d << CODE
> import std.net.curl;
>
> void main()
> {
> // get("dlang.org/non-existent-foobar"); // throws HTTPStatusException
> 404
> download("dlang.org/non-existent-foobar", "tmp"); // silently writes 404
> response, with no way to detect the error
> }
> CODE
>
> dmd -run bug
Below code works with error handling.
import std.stdio;
import std.net.curl;
void main()
{
auto url = "dlang.org/non-existent-foobar";
auto conn = HTTP(url);
download(url, "tmp", conn);
auto status = conn.statusLine();
if (status.code == 200){
writeln("Downloaded successfully!");
} else {
writefln("Failed to download. Error: %d %s", status.code,
status.reason);
}
}
--
[Issue 17941] arity (and probably others) only consider the first lexically present function
https://issues.dlang.org/show_bug.cgi?id=17941 Simen Kjaeraas changed: What|Removed |Added Component|dmd |phobos OS|Linux |All --- Comment #4 from Simen Kjaeraas --- (In reply to dechcaudron+dlang.issue.tracking from comment #3) > Maybe allow something of the sort > > static assert(arity!fun(int) == 1); > static assert(arity!gun(int, int) == 2); arity is an interesting case here, since it's hard to get the correct overload without knowing the arity already. :p The PR mentioned above would get the correct arity this way: static assert(arity!(overloadFor!(fun, int)) == 1); static assert(arity!(overloadFor!(gun, int, int)) == 2); > I had reported this as a Phobos issue (see above), but since it has been > marked as a duplicate for a dmd one, there's not much I can do. Compiler > stuff is still magic to me, I'm afraid. Fixing the issue in DMD would break a *lot* of code, and so isn't really feasible. I'm pretty sure it's not really desirable either, since the new semantics would be at least as weird as what we have. You could say the root issue is in DMD - templates operate on the first element when passed an overload set. The problem can however be ameliorated in Phobos, by giving programmers a way to specify which overload they mean. --
[Issue 18314] std.traits.getSymbolsByUDA only considers the first symbol of an overload set
https://issues.dlang.org/show_bug.cgi?id=18314 Simen Kjaeraas changed: What|Removed |Added Keywords||pull Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #2 from Simen Kjaeraas --- Actually, I was wrong here. While the root issue is the same, the way getSymbolsByUDA works should make it possible to fix it without addressing the issues in bug 17941. Fixed in this PR: https://github.com/dlang/phobos/pull/6085 --
[Issue 18322] void fun(string file=__FILE_FULL_PATH__)() returns relative path (pointing to nowhere)
https://issues.dlang.org/show_bug.cgi?id=18322 --- Comment #1 from Jonathan Marler --- Fix here: https://github.com/dlang/dmd/pull/7798 --
[Issue 18319] std.exception: enforce example does not compile
https://issues.dlang.org/show_bug.cgi?id=18319 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f4ccf68f2619f30d8fc684c6053625c13b311447 Fix Issue 18319 - std.exception: enforce example does not compile https://github.com/dlang/phobos/commit/afa7d586dd4632fdde995d1f2f34d9dde6b6a095 Merge pull request #6080 from wilzbach/fix-18319 Fix Issue 18319 - std.exception: enforce example does not compile --
[Issue 18319] std.exception: enforce example does not compile
https://issues.dlang.org/show_bug.cgi?id=18319 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17832] std.random.choice cannot be used with other random generators
https://issues.dlang.org/show_bug.cgi?id=17832 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/db5c1c84b9b344c28214463f7c94f83580363ded Addresses Issue 17832 Random choice default argument was deciding the type of the template. I'm not sure if this is a deeper bug, but it can easily be fixed with this patch which simply overloads the function. Also added a unittest which would have failed under the old code. https://github.com/dlang/phobos/commit/7823e1181d0a7e4698b77c7ba5fbbb25dcdebc7e Merge pull request #5741 from dunkyp/issue_17832 Fix Issue 17832 - std.random.choice cannot be used with other random generators --
[Issue 17832] std.random.choice cannot be used with other random generators
https://issues.dlang.org/show_bug.cgi?id=17832 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 18323] New: deprecate `void fun(this a)` (instead: typeof(this)) ; `var.init` (instead: typeof(var).init)
https://issues.dlang.org/show_bug.cgi?id=18323 Issue ID: 18323 Summary: deprecate `void fun(this a)` (instead: typeof(this)) ; `var.init` (instead: typeof(var).init) Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timothee.co...@gmail.com we should deprecate `void fun(this a)` (instead: void fun(typeof(this)a)) ; likewise, we should deprecate `var.init` (instead: typeof(var).init) more controversial: we may also want to deprecate `instance.static_methor();` it's confusing and lax, and leads to behavior that confuses some users, see [The daily D riddle]: https://www.mail-archive.com/digitalmars-d@puremagic.com/msg230090.html --
[Issue 18322] void fun(string file=__FILE_FULL_PATH__)() returns relative path (pointing to nowhere)
https://issues.dlang.org/show_bug.cgi?id=18322 Timothee Cour changed: What|Removed |Added CC||johnnymar...@gmail.com, ||razvan.nitu1...@gmail.com, ||timothee.co...@gmail.com --
[Issue 18322] New: void fun(string file=__FILE_FULL_PATH__)() returns relative path (pointing to nowhere)
https://issues.dlang.org/show_bug.cgi?id=18322
Issue ID: 18322
Summary: void fun(string file=__FILE_FULL_PATH__)() returns
relative path (pointing to nowhere)
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: timothee.co...@gmail.com
this is reminiscent of https://issues.dlang.org/show_bug.cgi?id=16640 but
different, and in fact worse since it returns a wrong relative path
dmd -Ifoo4 -run main.d
foo4/main.d #BUG: relative path pointing to nowhere
/path/to/main.d #OK: absolute path
files:
main.d
foo4/util.d
```
// main.d:
module main;
import util;
void main(){fun;}
// foo4/main.d:
module util;
void fun(string file1=__FILE_FULL_PATH__)(string file2=__FILE_FULL_PATH__){
import std.stdio;
writeln(file1); // BUG:relative path
writeln(file2); // OK
}
```
NOTE: calling it a regression because dmd 2.075 also returned a relative path
instead of absolute (which is wrong) but at least the relative path it returned
was correct instead of pointing to nowhere
--
