Jump to page: 1 2
Thread overview
[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld
Dec 17, 2015
Simon Na.
Dec 18, 2015
ZombineDev
Dec 18, 2015
ZombineDev
Dec 19, 2015
Simon Na.
Jun 25, 2017
Vladimir Panteleev
Jun 25, 2017
ZombineDev
Jun 25, 2017
Vladimir Panteleev
Jun 25, 2017
ag0aep6g@gmail.com
Jun 25, 2017
Vladimir Panteleev
Jun 25, 2017
ag0aep6g@gmail.com
Jun 25, 2017
Vladimir Panteleev
[Issue 15459] [REG2.065.0] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld
Jun 25, 2017
Vladimir Panteleev
Dec 14, 2018
Walter Bright
Dec 16, 2018
Simon Naarmann
Feb 12, 2020
Walter Bright
4 days ago
Dlang Bot
December 17, 2015
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
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
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
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
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
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
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
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
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
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?

--
« First   ‹ Prev
1 2