https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69265
--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #2) > Do you consider for options that take a Joined argument those corresponding > enum values? > I mean say provide hint for > -ftls-model=global-dinamic > to use > -ftls-model=global-dynamic > etc.? In the example you give, the user has got the option name correct, but has misspelled the enum value. Currently, we already give the user a sane error message for this case: $ gcc -ftls-model=global-dinamic -c foo.c gcc: error: unknown TLS model ‘global-dinamic’ gcc: note: valid arguments to ‘-ftls-model=’ are: global-dynamic initial-exec local-dynamic local-exec In theory we could add a hint to the error so it would become: $ gcc -ftls-model=global-dinamic -c foo.c gcc: error: unknown TLS model ‘global-dinamic’; did you mean 'global-dynamic'? gcc: note: valid arguments to ‘-ftls-model=’ are: global-dynamic initial-exec local-dynamic local-exec I can have a look at that. This PR has the users misspelling the option, rather than the arg. For example, if the user omits the "f" from -ftls-model: $ gcc -tls-model=global-dynamic -c foo.c gcc: error: unrecognized command line option ‘-tls-model=global-dynamic’ In theory we could populate the list of candidates with all of the various enum values, similiar to the patch in comment 1, which would give: $ gcc -tls-model=global-dynamic -c foo.c gcc: error: unrecognized command line option ‘-tls-model=global-dynamic’; did you mean ‘-ftls-model=global-dynamic’? > Harder will be options where the various enum values are not listed > in the *.opt file or somewhere easily accessible to the driver, say > -march=sandyridge > to use > -march=sandybridge (nods). This currently gives: $ gcc -c foo.c -march=sandyridge foo.c:1:0: error: bad value (sandyridge) for -march= switch I think it's acceptable to not hint for some cases. > The question is if for the joined options you should build all the possible > options joined with all the possible arguments and then hint among that, or > if you just should handle = sign specially and in this case also look at > -sanitize= > vs. -fsanitize= and separately for misspellings in the argument. > The -fsanitize= arguments are even more complicated because they actually > don't allow just one joined string, but allow > -fsanitize=integer-divide-by-zero,address,shift > etc. This is error-handling code. We're attempting to provide the user with a useful hint, but the attempt can fail, in which case we simply don't provide a hint. I think there are 3 approaches here: (A) build a vec of all possible combinations of option=arg that the user could type (B) split on the "=" char, compare edit-distances of the option, and then of the possible arguments, separately. (C) attempt (A), but avoid the more complicated cases I don't think it's reasonable to populate the list with all possible combinations of comma-separated args for -fsanitize (can options be repeated idepotently? if so there are infinite combinations), so that rules out (A). I'm not sure how well (B) would work; it seems useful to take it account the argument that was typed when determing which option the user might have meant. Also, if the user typoes "=" e.g. as "-" it doesn't help at all. (C) is what the patch in comment 1 implements: it builds "-fsanitize=ARG" candidates as if it were a mutex, which it isn't, but which at least ought to get better matches for if someone typos "-fsanitize" as in this PR. Approach (C) could also let us handle Joined arguments (though the patch in comment 1 doesn't do that yet).
