OptTable treats arguments starting with / that aren't a known option
as filenames. This means lld-link's and clang-cl's typo correction for
unknown flags didn't do spell checking for misspelled options that start
with /.
I first tried changing OptTable, but that got pretty messy, see PR41787
comments 2 and 3.
Instead, let lld-link's and clang's (including clang-cl's) "file not
found" diagnostic check if a non-existent file looks like it could be a
mis-spelled option, and if so add a "did you mean" suggestion to the
"file not found" diagnostic.
While here, make formatting of a few diagnostics a bit more
self-consistent.
Fixes PR41787.
Differential Revision: https://reviews.llvm.org/D62276
llvm-svn: 361518
Summary:
https://reviews.llvm.org/D46776 added better support for prefixes for the
"did you mean ...?" command line option suggestions. One of the tests was
checking against the `-debug-info-macro` option, which was failing on the
PS4 build bot. Tests would succeed against the `--help` and `--version`
options.
From https://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf, it
looks like the PS4 SDK forces optimizations and *could be* disabling the
`-debug-info-macro` altogether.
This diff removes `-debug-info-macro` altogether.
Patch by Arnaud Coomans!
Test Plan: untested since we do not have access to a PS4 with the SDK.
Reviewers: cfe-commits, modocache
Reviewed By: modocache
Differential Revision: https://reviews.llvm.org/D50410
llvm-svn: 341327
Summary:
When https://reviews.llvm.org/D46776 landed to improve the behavior of
`llvm::OptTable::findNearest`, a PS4 buildbot began failing due to an
assertion that a suggestion "-debug-info-macro" should be provided for
the unrecognized option `clang -cc1as -debug-info-macros`. All other
buildbots succeeded in this check, and the PS4 buildbot succeeded in the
other `findNearest` tests.
Temporarily loosen this check in order to reland the `findNearest`
change.
Test Plan: check-clang
llvm-svn: 332804
I discovered that '-i' is a command line option for the driver,
however it actually does not do anything and is not supported by any
other compiler. In fact, it is completely undocumented for Clang.
I found a couple of instances of people confusing it with one of
the variety of other command line options that control the driver.
Because of this, we should delete this option so that it is clear
that it isn't valid.
HOWEVER, I found that GCC DOES support -imultilib, which the -i
was hiding our lack of support for. We currently only use imultilib
for the purpose of forwarding to gfortran (in a specific test written
by chandlerc for this purpose).
imultilib is a rarely used (if ever?) feature that I could find no
references to on the internet, and in fact, my company's massive test
suite has zero references to it ever being used.
SO, this patch removes the -i option so that we will now give an error
on its usage (so that it won't be confused with -I), and replaces it with
-imultilib, which is now specified as a gfortran_group option.
Differential Revision: https://reviews.llvm.org/D44032
llvm-svn: 326623
Summary:
There are only two valid integrated Clang driver tools: `-cc1` and
`-cc1as`. If a user asks for an unknown tool, such as `-cc1asphalt`,
an error message is displayed to indicate that there is no such tool,
but the message doesn't indicate what the valid options are.
Include the valid options in the error message.
Test Plan: `check-clang`
Reviewers: sepavloff, bkramer, phosek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42004
llvm-svn: 322517
Summary:
In https://reviews.llvm.org/D41733, the driver was modified such that,
when a user provided a mispelled option such as `-hel`, it would
suggest a valid option with a nearby edit distance: "did you mean
'-help'?".
Add these suggestions to invocations of `clang -cc1as` as well.
Test Plan: `check-clang`
Reviewers: v.g.vassilev, bruno
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42001
llvm-svn: 322445
Summary:
The `llvm::OptTable::findNearest` bug fixed in
https://reviews.llvm.org/D41873 manifested itself as the following
erroneous message when invoking Clang:
```
clang -version
clang-6.0: error: unknown argument '-version', did you mean 'version'?
```
Add a test to catch any future regressions to the now correct behavior,
which asks "did you mean '--version'?".
Test Plan: `check-clang`
Reviewers: v.g.vassilev, teemperor, ruiu, jroelofs, yamaguchi
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41912
llvm-svn: 322220
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
This is recommit of r302775, reverted in r302777 due to a fail in
clang-tidy. Original mesage is below.
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 303756
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 302775
Summary:
MSVC's driver accepts all unknown arguments but warns about them. clang
by default rejects all unknown arguments. This causes issues
specifically with build systems such as autoconf which liberally pass
things such as $LDFLAGS to the compiler and expect everything to work.
This patch teaches clang-cl to ignore unknown driver arguments.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16511
llvm-svn: 258720
This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.
Other than the options clang explicitly claims to know, this fixes pr9701.
llvm-svn: 191249
Nico Weber