Posted a pull. Walter, please merge it. https://github.com/D-Programming-Language/dmd/pull/709

2012/2/11 Martin Nowak <dawg at dawgfoto.de>:
> While this will solve the current problem, the following code will remain
> broken.
> The root cause is contradicting preferences for variadic templates
> in deduceFunctionTemplateMatch and leastAsSpecialized.
>
> void foo(V)(in V v)     // A
> {
> }
>
> void foo(Args...)(auto ref const Args args)    // B
> {
> ? ?foo(cast(const(int))args[0]);
> }
>
> void main()
> {
> ? ?foo(10);
> }

What is "remain broken"? With my pull, foo(10) calls non variadic
version (A) as expected.

Kenji Hara

2012/2/11 Walter Bright <walter at digitalmars.com>:
> Do you mean the compiler seg faults or the compiled program seg faults?

Masahiro's original code compiles and succeeds to run in 2.057.
But it is compiles in 2.058beta, and segfault by infinite recursion.

This is a compiler regression. Fixing bug 6208 (merging dmd/pull/425) is not enough, it does not care the function parameter using tuple template parameter with storage classes.

I've posted a new pull dmd/pull/709 to fix the problem. Please merge it.

Kenji Hara

On Sat, 11 Feb 2012 13:13:33 +0100, kenji hara <k.hara.pg at gmail.com> wrote:

> Posted a pull. Walter, please merge it. https://github.com/D-Programming-Language/dmd/pull/709
>
> 2012/2/11 Martin Nowak <dawg at dawgfoto.de>:
>> While this will solve the current problem, the following code will
>> remain
>> broken.
>> The root cause is contradicting preferences for variadic templates
>> in deduceFunctionTemplateMatch and leastAsSpecialized.
>>
>> void foo(V)(in V v)     // A
>> {
>> }
>>
>> void foo(Args...)(auto ref const Args args)    // B
>> {
>>    foo(cast(const(int))args[0]);
>> }
>>
>> void main()
>> {
>>    foo(10);
>> }
>
> What is "remain broken"? With my pull, foo(10) calls non variadic
> version (A) as expected.
>
No your fix seems correct.
B with foo(10) should have been MATCHconst due to const Args.

I thought you would make a change because the inner call passes an lvalue.

2012/2/11 Martin Nowak <dawg at dawgfoto.de>:
> On Sat, 11 Feb 2012 13:13:33 +0100, kenji hara <k.hara.pg at gmail.com> wrote:
>
>> Posted a pull. Walter, please merge it. https://github.com/D-Programming-Language/dmd/pull/709
>>
>> 2012/2/11 Martin Nowak <dawg at dawgfoto.de>:
>>>
>>> While this will solve the current problem, the following code will remain
>>> broken.
>>> The root cause is contradicting preferences for variadic templates
>>> in deduceFunctionTemplateMatch and leastAsSpecialized.
>>>
>>> void foo(V)(in V v) ? ? // A
>>> {
>>> }
>>>
>>> void foo(Args...)(auto ref const Args args) ? ?// B
>>> {
>>> ? foo(cast(const(int))args[0]);
>>> }
>>>
>>> void main()
>>> {
>>> ? foo(10);
>>> }
>>
>>
>> What is "remain broken"? With my pull, foo(10) calls non variadic
>> version (A) as expected.
>>
> No your fix seems correct.
> B with foo(10) should have been MATCHconst due to const Args.
>
> I thought you would make a change because the inner call passes an lvalue.

In this case, `auto ref` in B is no meaning, because both `in V` and `auto ref const Args` match to both lvalue and rvalue.

Kenji Hara

Actually it's much worse than I thought.
We used to add aliases for selective imports, renamed imports and
module/package names.
But now they are handled by Import::search, i.e. after searching in the
current
scope has failed.
This causes a lot of regressions.

The old alias mechanism was fine, it only lacked the necessary access
checks.
I'm working on a purge now. We'd better reconsider this after fixing
access checks
during the next release.

-------------
#!/bin/sh
export DMD=dmd2.057
#export DMD=dmd2.058beta

echo ===== Regression 1 - Selective imports are not checked =====
cat > a.d << EOF
module a;
import b : nonexistent;
EOF

cat > b.d << EOF
module b;
EOF

${DMD} -c a.d

echo ===== Regression 2 - Import names no longer conflict with other
symbols =====
cat > a1.d << EOF
module a1;
import std.stdio;
int std;
EOF

${DMD} -c a1.d

cat > a2.d << EOF
module a2;
import std.stdio : writeln;
int writeln;
EOF

${DMD} -c a2.d

cat > a3.d << EOF
module a3;
import cstdio = std.stdio;
int cstdio;
EOF

${DMD} -c a3.d

echo ===== Regression 3 - Selective imports no longer overload =====
cat > a.d << EOF
module a;
import b : foo;

void foo(int) {}
void bar() { foo(); }
EOF

cat > b.d << EOF
module b;
void foo() {}
EOF

${DMD} -c a.d

I've posted a pull request. https://github.com/D-Programming-Language/dmd/pull/710

This is extremely unlucky to roll this back so late.
I will have a further look at it tomorrow to see how we can
fix this with the least possible friction.

I agree. We need to revert this, and add all the new failures into the test suite, so any future attempt at this won't screw it up again.

On 2/11/2012 12:52 PM, Martin Nowak wrote:
> I've posted a pull request. https://github.com/D-Programming-Language/dmd/pull/710
>
> This is extremely unlucky to roll this back so late.
> I will have a further look at it tomorrow to see how we can
> fix this with the least possible friction.
>

On Mon, 13 Feb 2012 02:07:33 +0100, Walter Bright <walter at digitalmars.com> wrote:

> I agree. We need to revert this, and add all the new failures into the test suite, so any future attempt at this won't screw it up again.
>
> On 2/11/2012 12:52 PM, Martin Nowak wrote:
>> I've posted a pull request. https://github.com/D-Programming-Language/dmd/pull/710
>>
>> This is extremely unlucky to roll this back so late.
>> I will have a further look at it tomorrow to see how we can
>> fix this with the least possible friction.
>>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

OK, there is one more fix for the remaining minor regression. https://github.com/D-Programming-Language/dmd/pull/713

The core issue to get imports right is that we add a lot of private symbols
to a module which in turn causes module interferences due to the access
vs. visible behavior.
Christian got around that by not adding the symbols and handling them
during symbol search instead.

If we shift to hiding protected symbols we can fix import AND protection.
It would also get rid of those incomprehensible symbol collisions and
reduce module conflicts.
Some care is required with base class lookup and overloading.
Do you see any further issues with that approach?

Let's give it a whirl.

On 2/12/2012 11:08 PM, Martin Nowak wrote:
> On Mon, 13 Feb 2012 02:07:33 +0100, Walter Bright <walter at digitalmars.com> wrote:
>
>> I agree. We need to revert this, and add all the new failures into the test suite, so any future attempt at this won't screw it up again.
>>
>> On 2/11/2012 12:52 PM, Martin Nowak wrote:
>>> I've posted a pull request. https://github.com/D-Programming-Language/dmd/pull/710
>>>
>>> This is extremely unlucky to roll this back so late.
>>> I will have a further look at it tomorrow to see how we can
>>> fix this with the least possible friction.
>>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
> OK, there is one more fix for the remaining minor regression. https://github.com/D-Programming-Language/dmd/pull/713
>
> The core issue to get imports right is that we add a lot of private symbols
> to a module which in turn causes module interferences due to the access vs.
> visible behavior.
> Christian got around that by not adding the symbols and handling them during
> symbol search instead.
>
> If we shift to hiding protected symbols we can fix import AND protection.
> It would also get rid of those incomprehensible symbol collisions and reduce
> module conflicts.
> Some care is required with base class lookup and overloading.
> Do you see any further issues with that approach?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>