Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 04, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ibuclaw@gdcproject.org See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=23595 --- Comment #1 from Iain Buclaw <ibuclaw@gdcproject.org> --- Related to issue 23595, and a WIP patch I have in the works fixes this test case too. -- |
January 04, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #2 from Max Samukha <maxsamukha@gmail.com> --- (In reply to Iain Buclaw from comment #1) > Related to issue 23595, and a WIP patch I have in the works fixes this test case too. Great! Thanks! -- |
January 16, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #3 from Dlang Bot <dlang-bot@dlang.rocks> --- @ibuclaw created dlang/dmd pull request #14826 "dmd.aggregate: Define importAll override for AggregateDeclaration" fixing this issue: - fix Issue 23598 - Another nasty forward reference bug https://github.com/dlang/dmd/pull/14826 -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@digitalmars.com --- Comment #4 from Walter Bright <bugzilla@digitalmars.com> --- Doing a shrink on the test case: alias aliases(a...) = a; template sort(alias f, a...) { static if (a.length > 0) { alias x = f!(a[0]); alias sort = a; } else alias sort = a; } alias SortedItems = sort!(isDependencyOf, String); enum isDependencyOf(Item) = Item.DirectDependencies.length == 0; struct String { alias DirectDependencies = aliases!(); enum l = SortedItems.length; // no property `length` } If SortedItems is moved last, it compiles successfully. -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #5 from Walter Bright <bugzilla@digitalmars.com> --- I suspect that when the sort template is instantiated, it is too eager to evaluate its arguments. It should just go as far as seeing String is a struct, and not attempt to semantic its contents. -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #6 from Walter Bright <bugzilla@digitalmars.com> --- What seems to be happening is the first time it goes through `template sort`, it cannot set `aliasdecl` because the two `alias sort` assignments are hidden behind conditional compilation. Hence `aliasdecl` is null. So, in semantic for `struct String` it encounters `SortedItems.length`. The `aliasdecl` is null, so `SortedItems` becomes `sort!(...)` which becomes `void` and there is no `length` for `void`. -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #7 from Walter Bright <bugzilla@digitalmars.com> --- Perhaps I can make this work by noticing if the `static if` member is the only member of the template, so it can be eagerly evaluated? -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #8 from Walter Bright <bugzilla@digitalmars.com> --- Looking at expandMembers, perhaps this could be done in two passes - once for the top level conditional compilation, then check oneMember, then again for the rest. -- |
January 19, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=10616, | |https://issues.dlang.org/sh | |ow_bug.cgi?id=20913, | |https://issues.dlang.org/sh | |ow_bug.cgi?id=22981 -- |
January 20, 2023 [Issue 23598] Another nasty forward reference bug | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23598 Max Samukha <maxsamukha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal --- Comment #9 from Max Samukha <maxsamukha@gmail.com> --- (In reply to Walter Bright from comment #8) > Looking at expandMembers, perhaps this could be done in two passes - once for the top level conditional compilation, then check oneMember, then again for the rest. I guess doing this won't solve the general problem. Perhaps, I should humble myself and resort to other means instead of trying to get from the compiler what it can't give. -- |
Copyright © 1999-2021 by the D Language Foundation