Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the twelfth batch of tests being updated (the end may be in
sight soon though).

show more ...

DebugInfo: Use clang's preferred names for integer types

This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - which
suggested this was done to improve consistency with the gdb test suit

DebugInfo: Use clang's preferred names for integer types

This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - which
suggested this was done to improve consistency with the gdb test suite.
Possible that at the time GCC did not canonicalize integer types, and so
matching types was important for cross-compiler validity, or that it was
only a case of over-constrained test cases that printed out/tested the
exact names of integer types.

In any case neither issue seems to exist today based on my limited
testing - both gdb and lldb canonicalize integer types (in a way that
happens to match Clang's preferred naming, incidentally) and so never
print the original text name produced in the DWARF by GCC or Clang.

This canonicalization appears to be in `integer_types_same_name_p` for
GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.

(I tested this with one translation unit defining 3 variables - `long`,
`long (*)()`, and `int (*)()`, and another translation unit that had
main, and a function that took `long (*)()` as a parameter - then
compiled them with mismatched compilers (either GCC+Clang, or
Clang+(Clang with this patch applied)) and no matter the combination,
despite the debug info for one CU naming the type "long int" and the
other naming it "long", both debuggers printed out the name as "long"
and were able to correctly perform overload resolution and pass the
`long int (*)()` variable to the `long (*)()` function parameter)

Did find one hiccup, identified by the lldb test suite - that CodeView
was relying on these names to map them to builtin types in that format.
So added some handling for that in LLVM. (these could be split out into
separate patches, but seems small enough to not warrant it - will do
that if there ends up needing any reverti/revisiting)

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

show more ...

Stop messing with the 'g' group of options in CompilerInvocation.

With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request de

Stop messing with the 'g' group of options in CompilerInvocation.

With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.

Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.

Differential Revision: http://reviews.llvm.org/D13221

llvm-svn: 249655

show more ...

DI: Update testcases for LLVM assembly change

Update testcases after LLVM change r243774.

Most of these had no need to check `tag:` field, but did so as a way of
getting to the `name:` field. In a

DI: Update testcases for LLVM assembly change

Update testcases after LLVM change r243774.

Most of these had no need to check `tag:` field, but did so as a way of
getting to the `name:` field. In a few cases I've converted the `tag:`
checks to `arg:` or `CHECK-NOT: arg:`.

llvm-svn: 243775

show more ...

DebugInfo: Metadata constructs now start with DI*

LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
comm

DebugInfo: Metadata constructs now start with DI*

LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.

llvm-svn: 236121

show more ...

DebugInfo: Move new hierarchy into place (clang)

Update testcases for LLVM change in r231082 to use the new debug info
hierarchy.

llvm-svn: 231083

IR: Make metadata typeless in assembly, clang side

Match LLVM changes from r224257.

llvm-svn: 224259

Revert "Revert "DI: LLVM schema change: fold constants into string""

This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.

--

Update debug info testcases f

Revert "Revert "DI: LLVM schema change: fold constants into string""

This reverts commit r218917, effectively reapplying r218913. Original
commit message follows.

--

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm-svn: 219011

show more ...

Revert "DI: LLVM schema change: fold constants into string"

This reverts commit r218913 while I investigate some bots.

llvm-svn: 218917

DI: LLVM schema change: fold constants into string

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm

DI: LLVM schema change: fold constants into string

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

llvm-svn: 218913

show more ...

Update CGDebugInfo to the updated API in LLVM.
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar:

Update CGDebugInfo to the updated API in LLVM.
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar://problem/17994491

llvm-svn: 218788

show more ...

Reverting r218777 while investigating buildbot breakage.
"Update CGDebugInfo to the updated API in LLVM."

llvm-svn: 218781

Update CGDebugInfo to the updated API in LLVM.
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar:

Update CGDebugInfo to the updated API in LLVM.
Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar://problem/17994491

llvm-svn: 218777

show more ...

Remove an empty line so the line numbers match up again after the recent documentation change.

llvm-svn: 179898

still not relaxed enough.

llvm-svn: 179897

cleanup and relax test cases

llvm-svn: 179896

Emit the underlying type in the debug info for all kinds of fixed enums
instead of only C++11-scoped-with-class-tag enums.

rdar://problem/13463793

llvm-svn: 179879