[Diagnostics] Add diagnostic for conflicting command-line options

[Steven Ramirez Rosa (Steven6798)]

Introduce a new diagnostic that detects and warns when mutually conflicting CLI flags are provided (e.g. --warn-mismatch vs --no-warn-mismatch). This helps prevent unintended or ambiguous behavior at invocation time by surfacing issues early.

Additionally, add the -W[no-]conflicting-options command line option to enable/disable this diagnostic.

Fix: #1222

[Shankar Easwaran (quic-seaswara)]

Can we cover incompatible use cases such as

• -Bdynamic and immediately followed by -Bstatic
• Partial linking (-r) with some of these flags
• -shared/-static
• --no-threads/--thread-count
• -static/-Bsymbolic/-Bsymbolic-functions

I might be missing a whole bunch of other options but this is a good start.

A one line describing why those options should not be combined would be useful for the reader.

[Steven Ramirez Rosa (Steven6798)]

Of course. I'll add those cases. If you find more cases that conflict with each other let me know.

[Shankar Easwaran (quic-seaswara)]

You might want to cover -z options too.

-z relro and -z norelro
-z separate-loadable-pages and --align-segments
-z now and -static
-z lazy and -static
-z lazy and -r

etc ...

[Steven Ramirez Rosa (Steven6798)]

Thanks. It looks like I missed a lot of cases. I'll move this PR to draft for now. Thanks!

[Steven Ramirez Rosa (Steven6798)]

I added these cases and more. I also refactored how the cases are handled. Let me know if you have any suggestions.

[Parth (parth-07)]

I am not sure how helpful this diagnostic option is.

warns when mutually conflicting CLI flags are provided (e.g. --warn-mismatch vs --no-warn-mismatch). This helps prevent unintended or ambiguous behavior at invocation time by surfacing issues early.

It is a common practice across tools to append a negative/positive option at the end to override the previous option. It is especially helpful during debugging.

Additionally, add the -W[no-]conflicting-options command line option to enable/disable this diagnostic.

What happens if there are conflicting -Wno-conflicting-options and -Wconflicting-options.

Can we cover incompatible use cases such as

-Bdynamic and immediately followed by -Bstatic

Combining -Bdynamic and -Bstatic has valid uses in selecting the right libraries. Adding a special case for reporting
a warning when -Bstatic is present immediately after -Bdynamic seems to be an overkill to me and not beneficial.

-shared/-static

In GNU ld, it is a well-defined behavior to use -static with -shared. It indicates that all the dependent libraries of the shared library getting created must be static libraries.

--no-threads/--thread-count

I think we can make --no-threads an alias of --thread-count=1, and then we would not need to handle the case --no-threads --thread-count=4 any differently from --thread-count=1 --thread-count=4

-static/-Bsymbolic/-Bsymbolic-functions

I worry that exhaustively covering all the cases here is much more efforts than the benefits it provides.

[Steven Ramirez Rosa (Steven6798)]

I am not sure how helpful this diagnostic option is.

It is helpful for debugging unexpected behavior of the linker. Specially for people that are not too familiar with the command line options or when there are lots of options in a command.

It is a common practice across tools to append a negative/positive option at the end to override the previous option. It is especially helpful during debugging.

That's why this warning can be turned on and off and is off by default.

What happens if there are conflicting -Wno-conflicting-options and -Wconflicting-options.

I can make a special case to handle this.

I worry that exhaustively covering all the cases here is much more efforts than the benefits it provides.

The work is already done so at this point it doesn't hurt.

[Parth (parth-07)]

It is helpful for debugging unexpected behavior of the linker. Specially for people that are not too familiar with the command line options or when there are lots of options in a command.

Have we found any real world use case where this option would have been helpful?

[Steven Ramirez Rosa (Steven6798)]

Have we found any real world use case where this option would have been helpful?

Shankar Easwaran (@quic-seaswara) might be able to answer this.

[Shankar Easwaran (quic-seaswara)]

I would like to suggest that this enhancement would provide a way to determine which command-line options are actually effective for the linker, and which ones the linker ultimately uses. These warnings would appear only with -Wconflicting-options.

Handling every conflicting and non-conflicting option on the command line is difficult, but we need to start somewhere.

I have seen users use combinations such as:

-static -pie -Bsymbolic --force-dynamic --dynamic-list <dyn> --version-script <vs> --no-pie
In some cases, from a build analysis perspective, I would like to know which options were actually honored by the linker.

This would be a first step toward telling the user that a given option was not used.

LLVM Clang already has similar behavior, where it emits a warning if a command-line option is not effective during compilation. I am suggesting that we implement the same behavior for the linker.

Hope this helps.

This is something new in the linker but at the same please continue on this and see how we can make it a better user experience.