On May 23, 2013, at 11:24 AM, Walter Bright <walter@digitalmars.com> wrote:

> I suspect some of these problems are caused by pull #93. To check, compile with:
>
>     -transition=field
>
> and add "static" to those declarations.

1. The initial message was still very bad
2. I need to know about the -translation flag
3. I fixed a couple of errors this flag found but the error message is still bad:

tango/io/selector/SelectSelector.d(115): tango.io.selector.SelectSelector.SelectSelector.DefaultSize is const field

https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/selector/PollSelector.d#L115

That is pointing to a commented line.

> On May 21, 2013, at 10:35 PM, Walter Bright <walter@digitalmars.com> wrote:
> 
> This message can happen if opAssign is generated, but the generated function failed to compile.

Since the function doesn't exist in the source file it's quite hard to find the actual error.

--
/Jacob Carlborg

2013/5/23 Jacob Carlborg <doob@me.com>

> There are a couple of errors in Tango. Tango compiled perfectly fine with the previous release, 2.062, without any warnings or deprecation messages.
>
> * tango/io/device/File.d(290): Error: cannot make expression out of
> initializer for ReadExisting
>
>
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/device/File.d#L290
>

Regression: http://d.puremagic.com/issues/show_bug.cgi?id=10142


> * tango/core/tools/StackTrace.d(186): Error: class
> tango.core.tools.StackTrace.BasicTraceInfo interface function 'string
> toString() const' is not implemented
>
>
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/core/tools/StackTrace.d#L186
>


This is expected change. The type of Throwable.TraceInfo.toString is
string() const, but BasicTraseInfo.toString is not const.
By fixing issue 8366, now const attribute is never inherited automatically.

Fixing way: Add const to BasicTraceInfo.toString

Reduced case:
    class BasicTraceInfo: Throwable.TraceInfo
    {
        override immutable(char)[] toString() /*const*/
        {
            immutable(char)[] ret;
            return ret;
        }
    }

* tango/io/selector/SelectSelector.d(156): Error: function
> tango.io.selector.SelectSelector.HandleSet.opAssign is not callable because it is annotated with @disable
>
>
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/selector/SelectSelector.d#L156
>
> Tango doesn't use @disable at all. "opAssign" is not overloaded.
>

Expected behavior. HandleSet.DefaultSize is a const int field, so HandleSet struct is not identity assignable.

Fixing way:
Change HandleSet.DefaultSize to enum or static.

Reduced case:
    struct BitArray // from tango.core.BitArray
    {
        this(this) {}
        // IF postblit exists, compiler will try to generate identity
opAssign implicitly.
        // -->  typeof(this) opAssign(typeof(this) rhs);
    }
    private struct HandleSet
    {
        /** Default number of handles that will be held in the HandleSet. */
        const uint DefaultSize = 1024;

        BitArray _buffer;
        // _buffer has opAssign, so HandleSet also need to generate
identity opAssign.
        // --> typeof(this) opAssign(typeof(this) rhs);
        // BUT, its smeantic would fail because DefaultSize field is not
assignable.
        // so generated opAssign would be implicitly annotated with
@disable.
        // --> typeof(this) opAssign(typeof(this) rhs) @disable;
    }
    void main()
    {
        HandleSet hs;
        hs = hs;    // @disable opAssign would be called, and fail to
compile
    }

* Error: cannot modify struct this HandleSet with immutable members
>
> No file or line information. Ok, I would the actual problem, but the error message is very unclear. There was a "const" member in HandleSet, it should have been static.
>
>
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/io/selector/SelectSelector.d#L783
>

Definitely a bug. I'm working for it...


> * tango/text/Regex.d(1779): Error: variable
> tango.text.Regex.TNFA!(dchar).TNFA.pca final cannot be applied to variable,
> perhaps you meant const?
> tango/text/Regex.d(2528): Error: template instance
> tango.text.Regex.TNFA!(dchar) error instantiating
> tango/text/Regex.d(3668):        instantiated from here: TDFA!(dchar)
> tango/text/Regex.d(4412):        instantiated from here: RegExpT!(char)
> tango/text/Regex.d(3668): Error: template instance
> tango.text.Regex.TDFA!(dchar) error instantiating
> tango/text/Regex.d(4412):        instantiated from here: RegExpT!(char)
> tango/text/Regex.d(4399): Error: tdfa_t.Command is used as a type
> tango/text/Regex.d(4412): Error: template instance
> tango.text.Regex.RegExpT!(char) error instantiatin
>
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/text/Regex.d#L1779
>
> There are no final variables in that file as far as I can see. The error message is pointing to an enum.
>

Regression: http://d.puremagic.com/issues/show_bug.cgi?id=10142

Kenji Hara

On Thursday, May 23, 2013 19:54:06 Kenji Hara wrote:
> 2013/5/23 Jacob Carlborg <doob@me.com>
> > * tango/core/tools/StackTrace.d(186): Error: class
> > tango.core.tools.StackTrace.BasicTraceInfo interface function 'string
> > toString() const' is not implemented
> > 
> > 
> > https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/core/tools/StackTr ace.d#L186
> This is expected change. The type of Throwable.TraceInfo.toString is
> string() const, but BasicTraseInfo.toString is not const.
> By fixing issue 8366, now const attribute is never inherited automatically.
> 
> Fixing way: Add const to BasicTraceInfo.toString
> 
> Reduced case:
>     class BasicTraceInfo: Throwable.TraceInfo
>     {
>         override immutable(char)[] toString() /*const*/
>         {
>             immutable(char)[] ret;
>             return ret;
>         }
>     }
> 
> * tango/io/selector/SelectSelector.d(156): Error: function

We really need to work on sorting out any remaining language changes like this so that we stop breaking code like this.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On May 23, 2013, at 12:54 PM, Kenji Hara <k.hara.pg@gmail.com> wrote:

>
> Regression: http://d.puremagic.com/issues/show_bug.cgi?id=10142

Thanks for the bug reports. But is this really the same issue as the first enum issue? The first is solved by replacing the C style initializer of the struct with a D style. Don't know about the second one.

--
/Jacob Carlborg

On May 23, 2013, at 10:19 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> If it's "Accepts Invalid," I wouldn't think that a deprecation message or warning would be appropriate. It's code that shouldn't even have compiled in the first place, not a feature that's been removed.

In this case I would guess "shared" on a "static" function would be noop. In that case a deprecation message could be used.

--
/Jacob Carlborg

That behavior has been introduced by fixing issue 9199. But the way was not
good, because it unnecessarily breaks existing code.
I opened a new enhancement
http://d.puremagic.com/issues/show_bug.cgi?id=10150 to fix the regressions
and more consistent compiler behavior. How about that?

Kenji Hara


2013/5/23 Jacob Carlborg <doob@me.com>

> On May 23, 2013, at 09:43 AM, Walter Bright <walter@digitalmars.com> wrote:
>
> Yes, but I don't know which one. The issue is attempting to declare:
>
> shared int foo() { ... }
>
> where shared would apply to the 'this' reference, but there is no 'this' reference. This was an "accepts invalid code" bug in the compiler.
>
>
> I absolutely agree. The change is correct. But there's no deprecation messages or warnings, I don't know if it would be possible though to add.
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

Honestly, issue 10142 contains a kind of enhancement.

From 2.063, all of enum values and enum members are internally wrapped by VarDeclaration to make UDA for them workable (== fixing issue 9652). But currently dmd disables abstract/override/final attribute for enum variable declarations.

class C {
    override enum int x1 = 1;   // currently NG
    abstract enum int x2 = 1;   // currently NG
    final enum int x3 = 1;   // currently NG

But I think this is unnecessary limitation. Relax such limitation would
automatically your first enum issue. So
10142 contains both regression fix and enhancement.

Note that the enhancement never break currently accepted code.

Kenji Hara


2013/5/23 Jacob Carlborg <doob@me.com>

>
>
> On May 23, 2013, at 12:54 PM, Kenji Hara <k.hara.pg@gmail.com> wrote:
>
>
> Regression: http://d.puremagic.com/issues/show_bug.cgi?id=10142
>
>
> Thanks for the bug reports. But is this really the same issue as the first enum issue? The first is solved by replacing the C style initializer of the struct with a D style. Don't know about the second one.
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

Regarding the current controversy on the NG (and in this mailing list) on const/immutable members with initializers, I would like to propose the following compromise (as posted in the NG):

1. Make a default-initialized const or immutable member an error.  It is not good to allow code with changed semantics (especially of this magnitude) to silently compile without intervention.
2. Disable the error with a switch (to allow for the new behavior).  I believe the current solution is to use a switch to *find* the possibly offending usages.  I think an opt-in approach is better.
3. In a future release, remove the error.

I reposted here, in case some are not watching that NG thread.

-Steve
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Thursday, May 23, 2013 11:52:41 Steven Schveighoffer wrote:
> 2. Disable the error with a switch
> (to allow for the new behavior). I believe the current solution is to use
> a switch to *find* the possibly offending usages. I think an opt-in
> approach is better.

The problem with it being opt-in is that it will break people's code without them even having a clue that anything was changed. The change needs to result in actual errors in their code, or they won't have a clue and won't fix their code.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 23 maj 2013, at 15:53, Kenji Hara <k.hara.pg@gmail.com> wrote:

> That behavior has been introduced by fixing issue 9199. But the way was not good, because it unnecessarily breaks existing code.
> I opened a new enhancement http://d.puremagic.com/issues/show_bug.cgi?id=10150 to fix the regressions and more consistent compiler behavior. How about that?


Sure, it's fine for me.

-- 
/Jacob Carlborg