This document is a first-stab at addressing some of the questions about
HLSL support in Clang.

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

Fix backward compatibility issue due to D120662.

Change-Id: I7cd0f704aabbaac7dcf59fd4b73b4f0e0cdfa69f

Reviewed By: yaxunl, saiislam

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

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

The LANGOPT macro allows you to specify a default value for the
langauge option. However, it's expected that these values be constant
rather than depending on other language options (because the
constructor setting the default values does not know the language mode
at the time it's being constructed).

Some of our language options were abusing this and passing in other
language mode options which were then set correctly by other parts of
frontend initialization. This removes the default values for the
language options, and then ensures they're consistently set from the
same place when setting language standard defaults.

Summary:
The `-fopenmp-target-new-runtime` flag has not been used for awhile. It
was present in a previous release so we shouldn't remove it for
backwards compatibility, but we shouldn't have documentation or a help
message for it.

This was skipping specific lifetime + bitcast patterns, but with
opaque pointers the bitcast will not be present, and we did not
perform this fold.

Instead skip over lifetime.end and bitcasts generally, without
trying to correlate them.

Align guards of these builtins with opencl-c.h.

This reverts commit fc2d8326.

I recently evaluated ~150 of bug reports on open source projects relating to my
GSoC'19 project, which was about tracking control dependencies that were
relevant to a bug report.

Here is what I found: when the condition is a function call, the extra notes
were almost always unimportant, and often times intrusive:

void f(int *x) {
  x = nullptr;
  if (alwaysTrue()) // We don't need a whole lot of explanation
                    // here, the function name is good enough.
    *x = 5;
}
It almost always boiled down to a few "Returning null pointer, which participates
in a condition later", or similar notes. I struggled to find a single case
where the notes revealed anything interesting or some previously hidden
correlation, which is kind of the point of condition tracking.

This patch checks whether the condition is a function call, and if so, bails
out.

The argument against the patch is the popular feedback we hear from some of our
users, namely that they can never have too much information. I was specifically
fishing for examples that display best that my contribution did more good than
harm, so admittedly I set the bar high, and one can argue that there can be
non-trivial trickery inside functions, and function names may not be that
descriptive.

My argument for the patch is all those reports that got longer without any
notable improvement in the report intelligibility. I think the few exceptional
cases where this patch would remove notable information are an acceptable
sacrifice in favor of more reports being leaner.

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

This adjusts the handling for:

export module  M;

export namespace {};

export namespace N {};
export using namespace N;

In the first case, we were allowing empty anonymous namespaces
as part of an extension allowing empty top-level entities, but that seems
inappropriate in this case, since the linkage would be internal for the
anonymous namespace.  We now report an error for this.

The second case was producing a warning diagnostic that this was
accepted as an extension - however the C++20 standard does allow this
as well-formed.

In the third case we keep the current practice that this is accepted with a
warning (as an extension). The C++20 standard says it's an error.

We also ensure that using decls are only applied to items with external linkage.

This adjusts error messages for exports involving redeclarations in modules to
be more specific about the reason that the decl has been rejected.

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

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.

This fixes #54715

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

The dependency scanner can reuse single FileManager instance across multiple translation units. This may lead to non-deterministic output depending on which TU gets processed first.

One of the problems is that Clang uses DirectoryEntry::getName in the header search algorithm. This function returns the path that was first used to construct the (shared) entry in FileManager. Using DirectoryEntryRef::getName instead preserves the case as it was spelled out for the current "get directory entry" request.

rdar://90647508

Reviewed By: dexonsmith

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

Reland Note: We've resolve the circular dependency issue on llvm/lib/Support and
llvm/TableGen.

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

This eliminates an unused-variable warning

Since the NTTP may need to be cast to the type when rebuilding the name,
check that the type can be rebuilt when determining whether a template
name can be simplified.

This reverts commit 2aae5b1f. Because it
breaks tests on windows.

This patch changes `EmitPPCBuiltinExpr` in `CGBuiltin.cpp` to remove
the loop at the beginning of the function that emits the arguments and
to delay emitting the arguments until inside the switch statement. These
changes will put `EmitPPCBuiltinExpr` in line with the strategy of the
target independent function `EmitBuiltinExpr`. Also, this patch
ensures that arguments are only emitted once.

Tests that included builtins affected by these changes have been
modified to match expected behaviour.

Reviewed By: #powerpc, nemanjai, amyk

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

We aim at improving the readability and maintainability of Options.td,
and in particular its handling of 'Flags', by
 - limiting the extent of 'let Flags = [...] in {'s, and
 - adding closing comments to matching '}'s.
 - being more consistent about empty lines around 'let Flags' and '}'.

More concretely,
 - we do not let a 'let Flags' span across several headline comments.
   When all 'def's in two consecutive headlines share the same flags,
   we stil close and start a new 'let Flags' at the intermediate
   headline.
 - when a 'let Flags' span just one or two 'def's, set 'Flags' within
   the 'def's instead.
 - we remove nested 'let Flags'.

Note that nested 'let Flags' can be quite confusing, especially when
the outer was started long before the inner. Moving a 'def' out of the
inner 'let Flags' and setting 'Flags' within the 'def' will not have the
intended effect, as those flags will be overridden by the outer
'let Flags'.

Reviewed By: awarzynski, jansvoboda11, hans

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

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

The code to check if the regular LTO summary should be emitted and to
add the corresponding module flags was duplicated in the
'EmitAssemblyHelper::EmitAssemblyWithLegacyPassManager' and
'EmitAssemblyHelper::RunOptimizationPipeline' methods.

In order to eliminate these code duplications, the
'EmitAssemblyHelper::shouldEmitRegularLTOSummary' method has been
extracted. The method returns a bool value, the value is 'true' if the
module summary should be emitted. The patch keeps the setting of the
module flags inline.

Reviewed By: tejohnson

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

Objective-C methods selector parts should be considered as identifiers.

Depends on D123259

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

We should only process APIs declared in the command line inputs to avoid
drowning the ExtractAPI output with symbols the user doesn't care about.
This is achieved by keeping track of the provided input files and
checking that the associated Decl or Macro is declared in one of those files.

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

There is a bug in `DeclarationFragments::appendSpace` where the space
character is added to a local copy of the last fragment.

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

- isValid: FileManager only ever returns valid FileEntries (see next point)

- construction from outside FileManager (both FileEntry and DirectoryEntry).
  It's not possible to create a useful FileEntry this way, there are no setters.
  This was only used in FileEntryTest, added a friend to enable this.
  A real constructor is cleaner but requires larger changes to FileManager.

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

This reverts commit 2aca33ba.
Broke tests on several bots, see comments on https://reviews.llvm.org/D120305

Internal symbol mangling is implementation-defined.  We do not mangle
any module attachment, and this adds a test to verify that.

Reviewed By: dblaikie

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

clang may throw the following warning:
include/clang/AST/DeclarationName.h:210:52: error: arithmetic between
different enumeration types ('clang::DeclarationName::StoredNameKind'
and 'clang::detail::DeclarationNameExtra::ExtraKind') is deprecated
when flags -Werror,-Wdeprecated-enum-enum-conversion are on.

This adds the `addEnumValues()` helper function to STLExtras.h to hide
the details of adding enumeration values together from two different
enumerations.

This was accidentally caught in an automated replacement. This
test is testing the -opaque-pointers flag itself, so we shouldn't
add -no-opaque-pointers here (though it doesn't hurt either).

Also drop the line testing the default, as the default is now
determined by a cmake option.

clang to emit DWARF information for global alias variable as
DW_TAG_imported_declaration. This change also handles nested
(recursive) imported declarations.

Reviewed by: dblaikie, aprantl

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

This adds the flag to more tests that were not caught by the
mass-migration in 532dc62b.

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

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

The error can be returned from the function, the problem written in comment before
does not exist. The same is done already in ASTImporter at various import failures.

After a declaration is created in an `ASTNodeImporter` import function
with `GetImportedOrCreateDecl`, that function registers it with
`MapImported`. At many places import errors can happen after this
and the error is returned. The same can be done in the place where
the in-class initializer is imported.

Reviewed By: martong

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

This option controls whether -opaque-pointers or -no-opaque-pointers
is the default. Once opaque pointers are enabled by default, this
will provide a simple way to temporarily opt-out of the change.

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

We would like to use bolt with Fuchsia toolchain.

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

(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

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

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