Skip to content

[lldb][swift] Ignore -- flag in swift-extra-clang-flags #2405

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

Teemperor
Copy link

-- indicates to Clang that all following arguments are file names (even when
they match a Clang compiler flag). This leads to the confusion situation
where LLDB users can run settings set target.swift-extra-clang-flags -- -v
and completely break the embedded Clang instance (that now tries to open the
file -v).

Fixes rdar://58457122

`--` indicates to Clang that all following arguments are file names (even when
they match a Clang compiler flag). This leads to the confusion situation
where LLDB users can run `settings set target.swift-extra-clang-flags -- -v`
and completely break the embedded Clang instance (that now tries to open the
file `-v`).

Fixes rdar://58457122
@Teemperor
Copy link
Author

@swift-ci test

@adrian-prantl
Copy link

Thanks! This will definitely work but I was wondering if the bug isn't in the generic llvm.org code:

(lldb) settings set target.swift-extra-clang-flags -- -v
(lldb) settings show target.swift-extra-clang-flags
target.swift-extra-clang-flags (string) = "-- -v"

According to your comment the -- is unnecessary, but:

(lldb) settings set target.swift-extra-clang-flags -v
error: unknown or ambiguous option

Ah!:

(lldb) settings set -- target.swift-extra-clang-flags -v
(lldb) settings show target.swift-extra-clang-flags 
target.swift-extra-clang-flags (string) = "-v"

You are right — this is not a bug at all.

@adrian-prantl
Copy link

I guess the cleanest solution would be to change the syntax of settings set or to make it print a warning if someone uses a trailing -- option.

(lldb) settings set target.swift-extra-clang-flags -- -v
warning: did you mean `settings set -- target.swift-extra-clang-flags -v`? You can suppress this warning by setting `....show-dashdash-warning false`.

@adrian-prantl
Copy link

@jimingham usually has well thought out opinions about UX questions like this.

@Teemperor
Copy link
Author

I think that's a bug with the settings set command parsing code. The command help says:

  settings set [-f] [-g <filename>] -- <setting-variable-name> <value>
  settings set <setting-variable-name> <value>

So -- shouldn't be necessary just to pass -flag behind the variable name. This also seems to break other stuff:

(lldb) settings set target.run-args -my-program-flag
error: unknown or ambiguous option
(lldb) settings set target.run-args "-my-program-flag"
error: unknown or ambiguous option

settings write/read is also relying on this format being accepted:

(lldb) settings set -- target.run-args "--foo"
(lldb) settings write -f ~/settings
(lldb) settings read -f ~/settings
Executing commands in '/Users/teemperor/settings'.
error: unknown or ambiguous option

@jimingham
Copy link

Remember that "settings set" is a raw command. The end of the help text for it says:

 This command takes options and free-form arguments.  If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.

It's like with "expr", even though the options are listed in the help, you still have to have a -- to use them.

The problem with raw commands is that each raw command does its own parsing, and I think the parsing for settings set is a little quirky.

@jimingham
Copy link

I've had problems getting some things past it before, though I can't recall the details at the moment.

@shahmishal shahmishal closed this Feb 2, 2021
@shahmishal shahmishal deleted the branch swiftlang:swift/rebranch February 2, 2021 02:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants