[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never pr

[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

Differential Revision: https://reviews.llvm.org/D122983

show more ...

Fix `sed -e s@FOO@%/S@` and similar when there's @'s in the working directory

Jenkins sometimes starts a new working directory by appending @2 (or
incrementing the number if the @n suffix is already

Fix `sed -e s@FOO@%/S@` and similar when there's @'s in the working directory

Jenkins sometimes starts a new working directory by appending @2 (or
incrementing the number if the @n suffix is already there). This causes
several clang tests to fail as:
s@INPUT_DIR@%/S/Inputs@g
gets expanded to the invalid:
s@INPUT_DIR@/path/to/workdir@2/Inputs@g
~~~~~~~~~~
where the part marked with ~'s is interpreted as the flags. These are
invalid and the test fails.

Previous fixes simply exchanged the @ character for another like | but
that's just moving the problem. Address it by adding an expansion that
escapes the @ character we're using as a delimiter as well as other magic
characters in the replacement of sed's s@@@.

There's still room for expansions to cause trouble though. One I ran into
while testing this was that having a directory called foo@bar causes lots
of `CHECK-NOT: foo` directives to match. There's also things like
directories containing `\1`

show more ...

Start porting ivfsoverlay tests to Windows

Part of PR43272, the changes are:

1. Use @ as the sed pattern delimiter instead of : so that the drive
letter in lit substitutions isn't an issue.

2. Use

Start porting ivfsoverlay tests to Windows

Part of PR43272, the changes are:

1. Use @ as the sed pattern delimiter instead of : so that the drive
letter in lit substitutions isn't an issue.

2. Use the %/t and %/S substitutions to get paths with forward slashes
to work around string quoting issues in the yaml file.

3. Replace REQUIRES:shell with XFAIL:windows. These tests should pass on
Windows, but do not for reasons that are not yet understood. We would
like to know if they pass unexpectedly.

I was able to remove the XFAILs from two tests, since they already pass
with my sed fix:
clang/test/VFS/module_missing_vfs.m
clang/test/VFS/test_nonmodular.c

Reviewers: amccarth

Differential Revision: https://reviews.llvm.org/D67454

llvm-svn: 371663

show more ...

[vfs] Don't bail out after a missing -ivfsoverlay file

This make -ivfsoverlay behave more like other fatal errors (e.g. missing
-include file) by skipping the missing file instead of bailing out of

[vfs] Don't bail out after a missing -ivfsoverlay file

This make -ivfsoverlay behave more like other fatal errors (e.g. missing
-include file) by skipping the missing file instead of bailing out of
the whole compilation. This makes it possible for libclang to still
provide some functionallity as well as to correctly produce the fatal
error diagnostic (previously we lost the diagnostic in libclang since
there was no TU to tie it to).

rdar://33385423

llvm-svn: 328337

show more ...