Thread overview | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 17, 2015 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 Simon Na. <eiderdaus@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|stdio.byLine.each!(map!some |stdin.byLine.each!(map!some |func) compiles, fails to |func) compiles, fails to |link with ld |link with ld -- |
December 18, 2015 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 ZombineDev <petar.p.kirov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |petar.p.kirov@gmail.com --- Comment #1 from ZombineDev <petar.p.kirov@gmail.com> --- When you're iterating any kind of string (char, wchar or dchar based) the element type is always dchar. This special case for narrow strings (UTF-8 and UTF-16) is also known as UTF autodecoding. You can see this for yourself if you change `somefunc` into a template and add a pragma statement to make the compiler emit an information message about the type of `c` for each instantiation of the function: auto somefunc(C)(C c) { pragma (msg, C); return c; } See also: http://dlang.org/phobos/std_range_primitives.html#.ElementType, http://dlang.org/phobos/std_range_primitives.html#.front and http://dlang.org/glossary.html#narrow strings This is still a valid bug report, because the compiler should refuse to compile this code. -- |
December 18, 2015 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 ZombineDev <petar.p.kirov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |accepts-invalid Hardware|x86_64 |All OS|Linux |All Severity|normal |major -- |
December 19, 2015 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 --- Comment #2 from Simon Na. <eiderdaus@gmail.com> --- Thanks for the thorough explanation! -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dlang-bugzilla@thecybershad | |ow.net Resolution|--- |INVALID --- Comment #3 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> --- The example presented is invalid, as the parameter of each is not expected to return anything, and map is lazy and by itself does not mutate global state (is pure if its predicate is). It also doesn't compile any more in the latest version of D. I'm closing this for now, but please reopen if you can provide a working practical example. -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 --- Comment #4 from ZombineDev <petar.p.kirov@gmail.com> --- Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that the compiler accepted the invalid example in the first place? -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 --- Comment #5 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> --- (In reply to ZombineDev from comment #4) > Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that the compiler accepted the invalid example in the first place? Well, the code wasn't technically invalid, just nonsensical. It stopped working after this PR: https://github.com/dlang/phobos/pull/5148 I'm not sure if that behavior change was intentional either, hence my comment there. There is also no practical difference between INVALID and WORKSFORME in practice, I think. -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 ag0aep6g@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |ag0aep6g@gmail.com Resolution|INVALID |--- --- Comment #6 from ag0aep6g@gmail.com --- (In reply to Vladimir Panteleev from comment #3) > I'm closing this for now, but please reopen if you can provide a working practical example. Reduced accepts-invalid: ---- enum e = is(typeof(map())); struct MapResult() { this(char[] a) {} char front() { dchar d; return d; /* should fail compilation */ } } void map()() { auto mr = MapResult!()([]); } void main() { map(); } -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 --- Comment #7 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> --- (In reply to ag0aep6g from comment #6) > (In reply to Vladimir Panteleev from comment #3) > > I'm closing this for now, but please reopen if you can provide a working practical example. > > Reduced accepts-invalid: This is not a valid reduction because .front is never called. The compiler seems to be skipping semantic analysis of uncalled functions here to avoid forward reference issues: https://github.com/dlang/dmd/pull/2851 -- |
June 25, 2017 [Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15459 --- Comment #8 from ag0aep6g@gmail.com --- (In reply to Vladimir Panteleev from comment #7) > This is not a valid reduction because .front is never called. front is never called in the original code either. > The compiler > seems to be skipping semantic analysis of uncalled functions here to avoid > forward reference issues: https://github.com/dlang/dmd/pull/2851 So the invalid front is supposed to be accepted (if it's never called)? Then I suppose the accepts-invalid aspect of this issue is WONTFIX. But it should link then, no? -- |
Copyright © 1999-2021 by the D Language Foundation