Bug #12050: Should feature processing really accept any substring of the feature name?

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN

[enebo (Thomas Enebo)]

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...

[nobu (Nobuyoshi Nakada)]

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.

[enebo (Thomas Enebo)]

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.

[enebo (Thomas Enebo)]

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?

[nobu (Nobuyoshi Nakada)]

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)

[usa (Usaku NAKAMURA)]

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.)

[nobu (Nobuyoshi Nakada)]

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.

[usa (Usaku NAKAMURA)]

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 :-)

[enebo (Thomas Enebo)]

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.

[nobu (Nobuyoshi Nakada)]

• 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]