RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 07:34, Brooks Moses wrote: > The Fortran front end currently has a lang.opt entry of the following form: > >ffixed-line-length- >Fortran RejectNegative Joined UInteger > > I would like to add to this the following option which differs in the > last character, but should be treated identically: > >ffixed-line-length= >Fortran RejectNegative Joined UInteger >In file included from tm.h:7, > from ../../svn-source/gcc/genconstants.c:32: >options.h:659: error: redefinition of `OPT_ffixed_line_length_' >options.h:657: error: `OPT_ffixed_line_length_' previously defined > here > > This is because both the '=' and the '-' in the option name reduce to a > '_' in the enumeration name, which of course causes the enumerator to > get defined twice -- and that's a problem, even though I'm quite happy > for the options to both be treated identically. > > There's not really any good way around this problem, is there? It may seem a bit radical, but is there any reason not to modify the option-parsing machinery so that either '-' or '=' are treated interchangeably for /all/ options with joined arguments? That is, whichever is specified in the .opt file, the parser accepts either? cheers, DaveK -- Can't think of a witty .sigline today
Re: How to create both -option-name-* and -option-name=* options?
Dave Korn wrote: > It may seem a bit radical, but is there any reason not to modify the > option-parsing machinery so that either '-' or '=' are treated interchangeably > for /all/ options with joined arguments? That is, whichever is specified in > the .opt file, the parser accepts either? I like that idea. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 20:06, Mark Mitchell wrote: > Dave Korn wrote: > >> It may seem a bit radical, but is there any reason not to modify the >> option-parsing machinery so that either '-' or '=' are treated >> interchangeably for /all/ options with joined arguments? That is, >> whichever is specified in the .opt file, the parser accepts either? > > I like that idea. Would it be a suitable solution to just provide a specialised wrapper around the two strncmp invocations in find_opt? It seems ok to me; we only want this change to affect comparisons, we call whichever form is listed in the .opts file the canonical form and just don't worry if the (canonical) way a flag is reported in an error message doesn't quite match when the non-canonical form was used on the command line? (I'm not even going to mention the 'limitation' that we are now no longer free to create -fFLAG=VALUE and -fFLAG-VALUE options with different meanings!) cheers, DaveK -- Can't think of a witty .sigline today
Re: How to create both -option-name-* and -option-name=* options?
Dave Korn wrote: > On 10 November 2006 20:06, Mark Mitchell wrote: > >> Dave Korn wrote: >> >>> It may seem a bit radical, but is there any reason not to modify the >>> option-parsing machinery so that either '-' or '=' are treated >>> interchangeably for /all/ options with joined arguments? That is, >>> whichever is specified in the .opt file, the parser accepts either? >> I like that idea. > > > Would it be a suitable solution to just provide a specialised wrapper around > the two strncmp invocations in find_opt? FWIW, that seems reasonable to me, but I've not looked hard at the code to be sure that's technically 100% correct. It certainly seems like the right idea. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: How to create both -option-name-* and -option-name=* options?
Dave Korn wrote: On 10 November 2006 20:06, Mark Mitchell wrote: Dave Korn wrote: It may seem a bit radical, but is there any reason not to modify the option-parsing machinery so that either '-' or '=' are treated interchangeably for /all/ options with joined arguments? That is, whichever is specified in the .opt file, the parser accepts either? I like that idea. Would it be a suitable solution to just provide a specialised wrapper around the two strncmp invocations in find_opt? It seems ok to me; we only want this change to affect comparisons, we call whichever form is listed in the .opts file the canonical form and just don't worry if the (canonical) way a flag is reported in an error message doesn't quite match when the non-canonical form was used on the command line? I would think that would be suitable, certainly. Having the error message report the canonical form would, to me, just be a beneficial small reminder to people to use the canonical form. (I'm not even going to mention the 'limitation' that we are now no longer free to create -fFLAG=VALUE and -fFLAG-VALUE options with different meanings!) But that's already not possible -- that's essentially how I got into this problem in the first place. If one tries to define both of those, the declaration of the enumeration-type holding the option flags breaks, so you can't do that. (Well, you could hack that to make it work; define -fFLAG as the option name, so that the '-' or '=' is the first character of the argument. That will still work, but it's a pain if VALUE is otherwise a UInteger.) This does raise a point about how the options are compared, though -- to be useful, this needs to also handle cases where a Joined option is emulated by a "normal" option. For instance, Fortran's lang.opt contains something like: -ffixed-line-length-none Fortran -ffixed-line-length- Fortran Joined We would also want "-ffixed-line-length=none" to be handled appropriately, which makes this a bit trickier than just handling the last character of Joined options. Are there any meaningful downsides to just having the option-matcher treat all '-' and '=' values in the option name as equivalent? It would mean that we'd also match "-ffixed=line=length-none", for instance, but I don't think that causes any real harm. An alternative would be to specify that an '=' in the name in the .opt file will match either '=' or '-' on the command line. This does require that the canonical form be the one with '=' in it, and means that things with '-' in them need to be changed in the .opt file to accept both, but the benefit is that it can accept pseudo-Joined options in either form without accepting all sorts of wierd things with random '='s in them. - Brooks
RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 21:18, Brooks Moses wrote: > Dave Korn wrote: > But that's already not possible -- that's essentially how I got into > this problem in the first place. If one tries to define both of those, > the declaration of the enumeration-type holding the option flags breaks, > so you can't do that. That aside, it would have been possible before, and the mangling could easily have been fixed to support it had we wanted to. > (Well, you could hack that to make it work; define -fFLAG as the option > name, so that the '-' or '=' is the first character of the argument. > That will still work, but it's a pain if VALUE is otherwise a UInteger.) Yeh, but it's also the right thing to do with the machinery as it stands. > This does raise a point about how the options are compared, though -- to > be useful, this needs to also handle cases where a Joined option is > emulated by a "normal" option. For instance, Fortran's lang.opt > contains something like: > >-ffixed-line-length-none >Fortran > >-ffixed-line-length- >Fortran Joined > > We would also want "-ffixed-line-length=none" to be handled > appropriately, which makes this a bit trickier than just handling the > last character of Joined options. > > Are there any meaningful downsides to just having the option-matcher > treat all '-' and '=' values in the option name as equivalent? It would > mean that we'd also match "-ffixed=line=length-none", for instance, but > I don't think that causes any real harm. I think it's horribly ugly! (Yes, this would not be a show-stopper in practice; I have a more serious reason to object, read on...) > An alternative would be to specify that an '=' in the name in the .opt > file will match either '=' or '-' on the command line. This does > require that the canonical form be the one with '=' in it, and means > that things with '-' in them need to be changed in the .opt file to > accept both, but the benefit is that it can accept pseudo-Joined options > in either form without accepting all sorts of wierd things with random > '='s in them. I think that for this one case we should just say that you have to supply both forms -ffixed-line-length-none and -ffixed-line-length=none. What you have here is really a joined option that has an argument that can be either a text field or an integer, and to save the trouble of parsing the field properly you're playing a trick on the options parser by specifying something that looks to the options machinery like a longer option with a common prefix, but looks to the human viewer like the same option with a text rather than integer parameter joined. Treating a trailing '-' as also matching a '=' (and vice-versa) doesn't blur the boundary between what are separate concepts in the option parsing machinery. I think if you really want these pseudo-joined fields, add support to the machinery to understand that the joined field can be either a string or a numeric. The change I'm proposing is kind of orthogonal to that. It solves your problem with the enum; there becomes only one enum to represent both forms and both forms are accepted and parse to that same enumerated value. It does not solve nor attempt to address your other problem, with the limitations on parsing joined fields, and I don't think we should try and bend it into shape to do this second job as well. If you address the parsing limitation on joined fields, the flexibility that my suggestion offers /will/ automatically be available to your usage. cheers, DaveK -- Can't think of a witty .sigline today
Re: How to create both -option-name-* and -option-name=* options?
Dave Korn wrote: On 10 November 2006 21:18, Brooks Moses wrote: But that's already not possible -- that's essentially how I got into this problem in the first place. If one tries to define both of those, the declaration of the enumeration-type holding the option flags breaks, so you can't do that. That aside, it would have been possible before, and the mangling could easily have been fixed to support it had we wanted to. Right, yeah -- my point was just that nobody _had_ fixed the mangling to support it, and thus that this was only eliminating a theoretical possibility rather than something someone might actually be doing, which means in practice it's not changing very much. Are there any meaningful downsides to just having the option-matcher treat all '-' and '=' values in the option name as equivalent? It would mean that we'd also match "-ffixed=line=length-none", for instance, but I don't think that causes any real harm. I think it's horribly ugly! (Yes, this would not be a show-stopper in practice; I have a more serious reason to object, read on...) I think it's horribly ugly, too -- but I don't see that the ugliness shows up anywhere unless some user is _intentionally_ doing something ugly; it just means that their ugly usage is rewarded by the compiler doing essentially what they expect, rather than throwing an error. An alternative would be to specify that an '=' in the name in the .opt file will match either '=' or '-' on the command line. This does require that the canonical form be the one with '=' in it, and means that things with '-' in them need to be changed in the .opt file to accept both, but the benefit is that it can accept pseudo-Joined options in either form without accepting all sorts of wierd things with random '='s in them. I think that for this one case we should just say that you have to supply both forms -ffixed-line-length-none and -ffixed-line-length=none. Which I would be glad to do, except that as far as I can tell, it's not possible to actually do that. The same problem arises there as arises when it doesn't have "none" on the end and "Joined" in the specification. What you have here is really a joined option that has an argument that can be either a text field or an integer, and to save the trouble of parsing the field properly you're playing a trick on the options parser by specifying something that looks to the options machinery like a longer option with a common prefix, but looks to the human viewer like the same option with a text rather than integer parameter joined. Right, agreed. Though it's not so much "to save the trouble" as "to be able to leverage all the useful things the option parser does to verify numeric fields". Treating a trailing '-' as also matching a '=' (and vice-versa) doesn't blur the boundary between what are separate concepts in the option parsing machinery. I think if you really want these pseudo-joined fields, add support to the machinery to understand that the joined field can be either a string or a numeric. Well, I'm not sure that I "want" them, exactly. They're only in gfortran because we're supporting backwards compatibity going back to the very early days of g77. The change I'm proposing is kind of orthogonal to that. It solves your problem with the enum; there becomes only one enum to represent both forms and both forms are accepted and parse to that same enumerated value. It does not solve nor attempt to address your other problem, with the limitations on parsing joined fields, and I don't think we should try and bend it into shape to do this second job as well. If you address the parsing limitation on joined fields, the flexibility that my suggestion offers /will/ automatically be available to your usage. Hmm. Valid points. And, given that adding support for both string and numeric values looks fairly easy (much more so than I would have guessed), that's probably the better way to go. A UIntegerOrString property would be incompatible with the Var property, since it would need two variables for storing the result, but I think this is not a notable loss since the combination of Var and UInteger is already rare -- the only flag that uses them both is -fabi-version. Or, given that the only thing that appears to use this at the moment is this old g77-style fixed-line-length Fortran option that we're only supporting for legacy purposes, I suppose we could just go for the cop-out of supporting the "-none" version and not the "=none" version, and only document it as accepting "=0". - Brooks
RE: How to create both -option-name-* and -option-name=* options?
On 11 November 2006 00:14, Brooks Moses wrote: > Dave Korn wrote: >> On 10 November 2006 21:18, Brooks Moses wrote: >> I think that for this one case we should just say that you have to supply >> both forms -ffixed-line-length-none and -ffixed-line-length=none. > > Which I would be glad to do, except that as far as I can tell, it's not > possible to actually do that. The same problem arises there as arises > when it doesn't have "none" on the end and "Joined" in the specification. Oh of couse. Hey, isn't this where I came in? >> What you have here is really a joined option that has an argument that >> can be either a text field or an integer, and to save the trouble of >> parsing the field properly you're playing a trick on the options parser by >> specifying something that looks to the options machinery like a longer >> option with a common prefix, but looks to the human viewer like the same >> option with a text rather than integer parameter joined. > > Right, agreed. Though it's not so much "to save the trouble" as "to be > able to leverage all the useful things the option parser does to verify > numeric fields". All the more reason to give the option parser even more useful things that it does that can be leveraged. > And, given that adding support for both string and numeric values looks > fairly easy (much more so than I would have guessed), that's probably > the better way to go. A UIntegerOrString property would be incompatible > with the Var property, since it would need two variables for storing the > result, but I think this is not a notable loss since the combination of > Var and UInteger is already rare -- the only flag that uses them both is > -fabi-version. > > Or, given that the only thing that appears to use this at the moment is > this old g77-style fixed-line-length Fortran option that we're only > supporting for legacy purposes, I suppose we could just go for the > cop-out of supporting the "-none" version and not the "=none" version, > and only document it as accepting "=0". Your choice; there's only a limited need to support ancient compile flags. Actually, perhaps you should fix this simply, by using a specs to rewrite the =none version into the -none version. Is there not a Fortran equivalent of CC1_SPEC/CC1PLUS_SPEC/... ? cheers, DaveK -- Can't think of a witty .sigline today
Re: How to create both -option-name-* and -option-name=* options?
Brooks Moses <[EMAIL PROTECTED]> writes: > Anyhow, if I try this, I get the following error (trimmed slightly for > clarity): > >gcc -c [...] ../../svn-source/gcc/genconstants.c >In file included from tm.h:7, > from ../../svn-source/gcc/genconstants.c:32: >options.h:659: error: redefinition of `OPT_ffixed_line_length_' >options.h:657: error: `OPT_ffixed_line_length_' previously defined > here > > This is because both the '=' and the '-' in the option name reduce to a > '_' in the enumeration name, which of course causes the enumerator to > get defined twice -- and that's a problem, even though I'm quite happy > for the options to both be treated identically. > > There's not really any good way around this problem, is there? I didn't see anyone mention this in the thread, so FWIW, we already have this problem with -finline-limit. The option scripts deal with it as a special case. I'm not saying that we should continue to do it like that... a more general approach is probably better. I just wanted to point out that there was precedent. Richard
