Project

General

Profile

Bug #12050

Should feature processing really accept any substring of the feature name?

Added by enebo (Thomas Enebo) about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:73700]

Description

ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise. If this is intentional it means no two features should ever start with the same letter...

Associated revisions

Revision 12bdb15e
Added by nobu (Nobuyoshi Nakada) about 3 years ago

ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@53772 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 53772
Added by nobu (Nobuyoshi Nakada) about 3 years ago

ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

Revision 53772
Added by nobu (Nobuyoshi Nakada) about 3 years ago

ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

Revision 53772
Added by nobu (Nobuyoshi Nakada) about 3 years ago

ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

Revision 53772
Added by nobu (Nobuyoshi Nakada) about 3 years ago

ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

History

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

Intentional, and resolved in the defined order when it is ambiguous.
I don't want to write --enable=frozen-string-literal, but --enable=frozen or shorter.

Updated by enebo (Thomas Enebo) about 3 years ago

Nobuyoshi Nakada wrote:

Intentional, and resolved in the defined order when it is ambiguous.
I don't want to write --enable=frozen-string-literal, but --enable=frozen or shorter.

ok. Thanks for the clarification.

Updated by enebo (Thomas Enebo) about 3 years ago

Thomas Enebo wrote:

Nobuyoshi Nakada wrote:

Intentional, and resolved in the defined order when it is ambiguous.
I don't want to write --enable=frozen-string-literal, but --enable=frozen or shorter.

ok. Thanks for the clarification.

Oh I should have read that closer...Resolves in the defined order if ambiguous? How would I know what that order is the defined order as an ordinary user?

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

ruby --help shows:

Features:
  gems            rubygems (default: enabled)
  did_you_mean    did_you_mean (default: enabled)
  rubyopt         RUBYOPT environment variable (default: enabled)
  frozen-string-literal
                  freeze all string literals (default: disabled)

Updated by usa (Usaku NAKAMURA) about 3 years ago

I hope that it should be an invalid option error if it is ambiguous.
And, when such case, showing the list of candidates (like did_you_mean) is better.

(Sorry, this comment may be a bikeshed.)

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

There is no ambiguous features now.
And, as for similar option, --dump which has parsetree and parsetree_with_comment, I don't want it to err by --dump=parse but to dump just parsetree.
Eliminating all ambiguities is not always convenient, I think.

Updated by usa (Usaku NAKAMURA) about 3 years ago

Nobuyoshi Nakada wrote:

Eliminating all ambiguities is not always convenient, I think.

The convenience is derived from your knowledge about the implementation.
For others who are not familiar with the implementation, the behavior is unpredictable.
The unpredictability may cause undesirable troubles.

Note that I don't talking about --dump option because it's for debugging the interpreter,
and the debugger should know well about the implementation :-)

Updated by enebo (Thomas Enebo) about 3 years ago

Usaku NAKAMURA wrote:

Nobuyoshi Nakada wrote:

Eliminating all ambiguities is not always convenient, I think.

The convenience is derived from your knowledge about the implementation.
For others who are not familiar with the implementation, the behavior is unpredictable.
The unpredictability may cause undesirable troubles.

Note that I don't talking about --dump option because it's for debugging the interpreter,
and the debugger should know well about the implementation :-)

I agree with you. For impl-specific options it is arguable whether ambiguity is important, but once enable/disable ends up with a potential ambiguous short-hand someone will end up getting confused.

The first feature encountered eliminates this ambiguity but I think most people would not expect this heuristic and they would expect an error on ambiguous entry. Of course, that is just one opinion :) Also, perhaps there will never be enough enable/disable options where they are ambiguous features.

#9

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

  • Status changed from Open to Closed

Applied in changeset r53772.


ruby.c: err ambiguous feature name [ci skip]

  • ruby.c (feature_option): raise a runtime error if ambiguous feature name is given, in the future. [Bug #12050]

Also available in: Atom PDF