[PATCH] D135076: [Clang] Make offloading flags accept '-' and '--'

Mon Oct 3 11:29:03 PDT 2022

jhuber6 added a comment.

In D135076#3831340 <https://reviews.llvm.org/D135076#3831340>, @MaskRay wrote:

> In D135076#3831307 <https://reviews.llvm.org/D135076#3831307>, @jhuber6 wrote:
>
>> In D135076#3831298 <https://reviews.llvm.org/D135076#3831298>, @MaskRay wrote:
>>
>>> We really want these `--offload-*` users to stick with one canonical form, not `-offload-*` in some places while `--offload-*` in other places.
>>>
>>> Another angle is that people find `-offload-*` working with a new clang may try `-offload-*` on an old clang and get `-o ffload-*`.
>>>
>>> And `-offload-*` doesn't help misspelled options.
>>
>> This is fine, as long as users get more distinct feedback that `-offload-arch` isn't doing what they think it does. Normally we'd get some error and a helpful suggestion if the option is misspelled, but with `-o` options we don't get anything.
>> My only qualm with the current state is that it's not obvious that `-offload-arch` is actually `-o ffload-arch` for most cases.
>
> You can make `-oxxx` an error if offloading is used (`-o xxx` is still allowed). Then no `--offload-*` needs a `-offload-*` form.

The problem here is that the `--offload-*` options are used to enable the offloading toolchain for some targets (e.g. OpenMP). Would a check on `-o' that emits a warning if it matches closely a known option work? E.g. `-offload-arch` would warn that the user may mean `--offload-arch`.

> This patch probably provides some convenience but regresses other aspects, and I think it should be reverted.

If you think this should be reverted then I'm fine with it. I would like to see some kind of solution to this problem however, as I have dealt with this problem many times when working with users.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135076/new/

https://reviews.llvm.org/D135076