May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| 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 |
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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 |
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara Attachments:
|
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
|
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis Attachments:
| 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
|
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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 > |
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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
>
|
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
May 23, 2013 Re: [dmd-beta] dmd 2.063 beta 5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara Attachments:
| 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 |
Copyright © 1999-2021 by the D Language Foundation