Commit Graph

787 Commits

Author SHA1 Message Date
Anton Zabaznov e123cd674c [OpenCL] Refactor of targets OpenCL option settings
Currently, there is some refactoring needed in existing interface of OpenCL option
settings to support OpenCL C 3.0. The problem is that OpenCL extensions and features
are not only determined by the target platform but also by the OpenCL version.
Also, there are core extensions/features which are supported unconditionally in
specific OpenCL C version. In fact, these rules are not being followed for all targets.
For example, there are some targets (as nvptx and r600) which don't support
OpenCL C 2.0 core features (nvptx.languageOptsOpenCL.cl, r600.languageOptsOpenCL.cl).

After the change there will be explicit differentiation between optional core and core
OpenCL features which allows giving diagnostics if target doesn't support any of
necessary core features for specific OpenCL version.

This patch also eliminates `OpenCLOptions` instance duplication from `TargetOptions`.
`OpenCLOptions` instance should take place in `Sema` as it's going to be modified
during parsing. Removing this duplication will also allow to generally simplify
`OpenCLOptions` class for parsing purposes.

Reviewed By: Anastasia

Differential Revision: https://reviews.llvm.org/D92277
2021-01-25 19:50:23 +03:00
Yaxun (Sam) Liu 622eaa4a4c [HIP] Support __managed__ attribute
This patch implements codegen for __managed__ variable attribute for HIP.

Diagnostics will be added later.

Differential Revision: https://reviews.llvm.org/D94814
2021-01-22 11:43:58 -05:00
Sean Dooher 35c9baa11e [attributes] Add a facility for enforcing a Trusted Computing Base.
Introduce a function attribute 'enforce_tcb' that prevents the function
from calling other functions without the same attribute. This allows
isolating code that's considered to be somehow privileged so that it could not
use its privileges to exhibit arbitrary behavior.

Introduce an on-by-default warning '-Wtcb-enforcement' that warns
about violations of the above rule.

Introduce a function attribute 'enforce_tcb_leaf' that suppresses
the new warning within the function it is attached to. Such leaf functions
may implement common functionality between the trusted and the untrusted code
but they require extra careful audit with respect to their capabilities.

Fixes after a revert in 419ef38a50293c58078f830517f5e305068dbee6:
Fix a test.
Add workaround for GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274).
Attribute the patch appropriately!

Differential Revision: https://reviews.llvm.org/D91898
2021-01-11 10:20:51 -08:00
Matthew Voss 0386f3d4f4 [NFC] Specify C11 in loop-opt-setup.c
This test was failing in our internal CI, since our driver does not default to
C11. Adding this switch fixes the issue.

Differential Revision: https://reviews.llvm.org/D94327
2021-01-08 12:15:26 -08:00
Anastasia Stulova 0e874fc014 [OpenCL] Add clang extension for variadic functions.
With the internal clang extension '__cl_clang_variadic_functions'
variadic functions are accepted by the frontend.

This is not a fully supported vendor/Khronos extension
as it can only be used on targets with variadic prototype
support or in metaprogramming to represent functions with
generic prototype without calling such functions in the
kernel code.

Tags: #clang

Differential Revision: https://reviews.llvm.org/D94027
2021-01-06 20:39:57 +00:00
Anastasia Stulova 4fde2b6a0c [OpenCL] Add clang extension for function pointers.
The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.

This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.

Tags: #clang

Differential Revision: https://reviews.llvm.org/D94021
2021-01-06 20:39:57 +00:00
Atmn Patel f88a797521 [LoopDeletion] Allows deletion of possibly infinite side-effect free loops
From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.

This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.

Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D86844
2021-01-05 09:56:16 -05:00
Valeriy Savchenko fec1a442e3 [-Wcalled-once-parameter] Introduce 'called_once' attribute
This commit introduces a new attribute `called_once`.
It can be applied to function-like parameters to signify that
this parameter should be called exactly once.  This concept
is particularly widespread in asynchronous programs.

Additionally, this commit introduce a new group of dataflow
analysis-based warnings to check this property.  It identifies
and reports the following situations:
  * parameter is called twice
  * parameter is never called
  * parameter is not called on one of the paths

Current implementation can also automatically infer `called_once`
attribute for completion handler paramaters that should follow the
same principle by convention.  This behavior is OFF by default and
can be turned on by using `-Wcompletion-handler`.

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

rdar://72812043
2021-01-05 18:26:44 +03:00
Atmn 1a65b8c739 [Clang][Misc] Change run line in fragile test
This test has %clang in the run line when it should have %clang_cc1.
This should prevent future release test failures.

Differential Revision: https://reviews.llvm.org/D93952
2020-12-31 13:48:21 -05:00
Bogdan Graur 8bee4d4e8f Revert "[LoopDeletion] Allows deletion of possibly infinite side-effect free loops"
Test clang/test/Misc/loop-opt-setup.c fails when executed in Release.

This reverts commit 6f1503d598.

Reviewed By: SureYeaah

Differential Revision: https://reviews.llvm.org/D93956
2020-12-31 11:47:49 +00:00
Atmn Patel 6f1503d598 [LoopDeletion] Allows deletion of possibly infinite side-effect free loops
From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.

This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.

Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D86844
2020-12-30 21:43:01 -05:00
Duncan P. N. Exon Smith 245218bb35 Basic: Support named pipes natively in SourceManager and FileManager
Handle named pipes natively in SourceManager and FileManager, removing a
call to `SourceManager::overrideFileContents` in
`CompilerInstance::InitializeSourceManager` (removing a blocker for
sinking the content cache to FileManager (which will incidently sink
this new named pipe logic with it)).

SourceManager usually checks if the file entry's size matches the
eventually loaded buffer, but that's now skipped for named pipes since
the `stat` won't reflect the full size.  Since we can't trust
`ContentsEntry->getSize()`, we also need shift the check for files that
are too large until after the buffer is loaded... and load the buffer
immediately in `createFileID` so that no client gets a bad value from
`ContentCache::getSize`. `FileManager::getBufferForFile` also needs to
treat these files as volatile when loading the buffer.

Native support in SourceManager / FileManager means that named pipes can
also be `#include`d, and clang/test/Misc/dev-fd-fs.c was expanded to
check for that.

This is a new version of 3b18a594c7, which
was reverted in b346322019 since it was
missing the `SourceManager` changes.

Differential Revision: https://reviews.llvm.org/D92531
2020-12-23 14:57:41 -08:00
Zequan Wu fb0f728805 [Clang] Make nomerge attribute a function attribute as well as a statement attribute.
Differential Revision: https://reviews.llvm.org/D92800
2020-12-17 07:45:38 -08:00
Johannes Doerfert bc7126b2bc [FIX] Add the comma missing in D91979 2020-12-15 17:24:53 -06:00
Johannes Doerfert b9c77542e2 [Clang][Attr] Introduce the `assume` function attribute
The `assume` attribute is a way to provide additional, arbitrary
information to the optimizer. For now, assumptions are restricted to
strings which will be accumulated for a function and emitted as comma
separated string function attribute. The key of the LLVM-IR function
attribute is `llvm.assume`. Similar to `llvm.assume` and
`__builtin_assume`, the `assume` attribute provides a user defined
assumption to the compiler.

A follow up patch will introduce an LLVM-core API to query the
assumptions attached to a function. We also expect to add more options,
e.g., expression arguments, to the `assume` attribute later on.

The `omp [begin] asssumes` pragma will leverage this attribute and
expose the functionality in the absence of OpenMP.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D91979
2020-12-15 16:51:34 -06:00
Gulfem Savrun Yeniceri 7c0e3a77bc [clang][IR] Add support for leaf attribute
This patch adds support for leaf attribute as an optimization hint
in Clang/LLVM.

Differential Revision: https://reviews.llvm.org/D90275
2020-12-14 14:48:17 -08:00
Tony 7beee561e2 [AMDGPU] Add missing targets to target-invalid-cpu-note.c
Differential Revision: https://reviews.llvm.org/D93018
2020-12-12 18:19:03 +00:00
Fangrui Song 754d1d3d52 [test] Fix Misc/time-passes.c 2020-12-09 17:17:28 -08:00
Yuanfang Chen 1821265db6 [Time-report] Add a flag -ftime-report={per-pass,per-pass-run} to control the pass timing aggregation
Currently, -ftime-report + new pass manager emits one line of report for each
pass run. This potentially causes huge output text especially with regular LTO
or large single file (Obeserved in private tests and was reported in D51276).
The behaviour of -ftime-report + legacy pass manager is
emitting one line of report for each pass object which has relatively reasonable
text output size. This patch adds a flag `-ftime-report=` to control time report
aggregation for new pass manager.

The flag is for new pass manager only. Using it with legacy pass manager gives
an error. It is a driver and cc1 flag. `per-pass` is the new default so
`-ftime-report` is aliased to `-ftime-report=per-pass`. Before this patch,
functionality-wise `-ftime-report` is aliased to `-ftime-report=per-pass-run`.

* Adds an boolean variable TimePassesHandler::PerRun to control per-pass vs per-pass-run.
* Adds a new clang CodeGen flag CodeGenOptions::TimePassesPerRun to work with the existing CodeGenOptions::TimePasses.
* Remove FrontendOptions::ShowTimers, its uses are replaced by the existing CodeGenOptions::TimePasses.
* Remove FrontendTimesIsEnabled (It was introduced in D45619 which was largely reverted.)

Differential Revision: https://reviews.llvm.org/D92436
2020-12-08 10:13:19 -08:00
Erik Pilkington 5a28e1d9e5 [clang] Add support for attribute 'swift_async'
This attributes specifies how (or if) a given function or method will be
imported into a swift async method. rdar://70111252

Differential revision: https://reviews.llvm.org/D92742
2020-12-07 17:19:26 -05:00
Alex Lorenz eddd1d192b [clang] add a `swift_async_name` attribute
The swift_async_name attribute provides a name for a function/method that can be used
to call the async overload of this method from Swift. This name specified in this attribute
assumes that the last parameter in the function/method its applied to is removed when
Swift invokes it, as the the Swift's await/async transformation implicitly constructs the callback.

Differential Revision: https://reviews.llvm.org/D92355
2020-12-04 15:55:29 -08:00
Aaron Puchert dea31f135c Consistent spelling in diagnostics: {l,r}value instead of {l,r}-value
As Richard Smith pointed out in the review of D90123, both the C and C++
standard call it lvalue and rvalue, so let's stick to the same spelling
in Clang.
2020-11-15 18:05:11 +01:00
Richard Smith 7602ef768b Suppress trailing template arguments equivalent to default arguments
when printing the name of a member of a class template specialization.
2020-11-12 21:10:34 -08:00
Richard Smith 5f12f4ff90 Suppress printing of inline namespace names in diagnostics by default,
except where they are necessary to disambiguate the target.

This substantially improves diagnostics from the standard library,
which are otherwise full of `::__1::` noise.
2020-11-11 15:05:51 -08:00
Richard Smith e7f3e2103c Suppress printing template arguments that match default template
arguments of types by default.

This somewhat improves the worst-case printing of types like
std::string, std::vector, etc., where many irrelevant default arguments
can be included in the type as printed if we've lost the type sugar.
2020-11-11 15:05:51 -08:00
Tyker d093401a26 [NFC] Remove string parameter of annotation attribute from AST childs.
this simplifies using annotation attributes when using clang as library
2020-11-09 16:39:59 +01:00
Fangrui Song d2da05de7c [test] Fix Other/new-pass-manager.ll & clang/test/Misc/loop-opt-setup.c 2020-11-06 21:55:11 -08:00
Atmn Patel 569abb530e [LoopDeletion] Fixes failing test
The commit 0b17c6e447 occasionally causes this test to
fail, this fixes it.
2020-11-06 22:45:28 -05:00
Atmn Patel 0b17c6e447 [LoopDeletion] Allows deletion of possibly infinite side-effect free loops
From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.

This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.

Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D86844
2020-11-06 22:06:58 -05:00
Ben Shi 5be50d79c0 [NFC][clang][AVR] Add more devices
Reviewed By: dylanmckay

Differential Revision: https://reviews.llvm.org/D88352
2020-10-29 11:49:21 +08:00
Tyker d3205bbca3 [Annotation] Allows annotation to carry some additional constant arguments.
This allows using annotation in a much more contexts than it currently has.
especially when annotation with template or constexpr.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D88645
2020-10-26 10:50:05 +01:00
Benjamin Kramer 39a0d6889d [X86] Add a stub for Intel's alderlake.
No scheduling, no autodetection.
2020-10-24 19:01:22 +02:00
Benjamin Kramer bd2cf96c09 [X86] Add a stub for znver3 based on the little public information there is in AMD's manuals
No scheduling, no autodetection. Just enough so -march=znver3 works.
2020-10-24 19:01:22 +02:00
Marco Antognini a779a16993 [OpenCL] Remove unused extensions
Many non-language extensions are defined but also unused. This patch
removes them with their tests as they do not require compiler support.

The cl_khr_select_fprounding_mode extension is also removed because it
has been deprecated since OpenCL 1.1 and Clang doesn't have any specific
support for it.

The cl_khr_context_abort extension is only referred to in "The OpenCL
Specification", version 1.2 and 2.0, in Table 4.3, but no specification
is provided in "The OpenCL Extension Specification" for these versions.
Because it is both unused in Clang and lacks specification, this
extension is removed.

The following extensions are platform extensions that bring new OpenCL
APIs but do not impact the kernel language nor require compiler support.
They are therefore removed.

- cl_khr_gl_sharing, introduced in OpenCL 1.0

- cl_khr_icd, introduced in OpenCL 1.2

- cl_khr_gl_event, introduced in OpenCL 1.1
Note: this extension adds a new API to create cl_event but it also
specifies that these can only be used by clEnqueueAcquireGLObjects.
Hence, they cannot be used on the device side and the extension does
not impact the kernel language.

- cl_khr_d3d10_sharing, introduced in OpenCL 1.1

- cl_khr_d3d11_sharing, introduced in OpenCL 1.2

- cl_khr_dx9_media_sharing, introduced in OpenCL 1.2

- cl_khr_image2d_from_buffer, introduced in OpenCL 1.2

- cl_khr_initialize_memory, introduced in OpenCL 1.2

- cl_khr_gl_depth_images, introduced in OpenCL 1.2
Note: this extension is related to cl_khr_depth_images but only the
latter adds new features to the kernel language.

- cl_khr_spir, introduced in OpenCL 1.2

- cl_khr_egl_event, introduced in OpenCL 1.2
Note: this extension adds a new API to create cl_event but it also
specifies that these can only be used by clEnqueueAcquire* API
functions. Hence, they cannot be used on the device side and the
extension does not impact the kernel language.

- cl_khr_egl_image, introduced in OpenCL 1.2

- cl_khr_terminate_context, introduced in OpenCL 1.2

The minimum required OpenCL version used in OpenCLExtensions.def for
these extensions is not always correct. Removing these address that
issue.

Reviewed By: Anastasia

Differential Revision: https://reviews.llvm.org/D89372
2020-10-22 17:01:31 +01:00
Fangrui Song 2484e9159c [Driver] Clean up -gz & --compress-debug-sections
* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib
* Make -gz an alias for -gz=zlib

The new behavior is consistent with GCC when binutils>=2.26 is detected:
-gz is translated to --compress-debug-sections=zlib instead of --compress-debug-sections.
2020-10-19 23:06:33 -07:00
Richard Smith 552c6c2328 PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.
Old GCC used to aggressively fold VLAs to constant-bound arrays at block
scope in GNU mode. That's non-conforming, and more modern versions of
GCC only do this at file scope. Update Clang to do the same.

Also promote the warning for this from off-by-default to on-by-default
in all cases; more recent versions of GCC likewise warn on this by
default.

This is still slightly more permissive than GCC, as pointed out in
PR44406, as we still fold VLAs to constant arrays in structs, but that
seems justifiable given that we don't support VLA-in-struct (and don't
intend to ever support it), but GCC does.

Differential Revision: https://reviews.llvm.org/D89523
2020-10-16 14:34:35 -07:00
Kito Cheng cfa7094e49 [RISCV] Add -mtune support
- The goal of this patch is improve option compatible with RISCV-V GCC,
   -mcpu support on GCC side will sent patch in next few days.

 - -mtune only affect the pipeline model and non-arch/extension related
   target feature, e.g. instruction fusion; in td file it called
   TuneFeatures, which is introduced by X86 back-end[1].

 - -mtune accept all valid option for -mcpu and extra alias processor
   option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is
   option compatible with RISCV-V GCC.

 - Processor alias for -mtune will resolve according the current target arch,
   rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`.

 - Interaction between -mcpu and -mtune:
   * -mtune has higher priority than -mcpu for pipeline model and
     TuneFeatures.

[1] https://reviews.llvm.org/D85165

Reviewed By: luismarques

Differential Revision: https://reviews.llvm.org/D89025
2020-10-16 13:55:08 +08:00
Fangrui Song 012dd42e02 [X86] Support -march=x86-64-v[234]
PR47686. These micro-architecture levels are defined in the x86-64 psABI:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9

GCC 11 will support these levels.

Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be
used on them.

Reviewed By: craig.topper, RKSimon

Differential Revision: https://reviews.llvm.org/D89197
2020-10-12 10:29:46 -07:00
Tim Renouf 666ef0db20 [AMDGPU] Add gfx602, gfx705, gfx805 targets
At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This commit is part of fixing that by adding three new
targets:

* The "Oland" and "Hainan" variants of gfx601 are now split out into
  gfx602. LLPC (in the GPUOpen driver) and other front-ends could use
  that to avoid using the shaderZExport workaround on gfx602.

* One variant of gfx703 is now split out into gfx705. LLPC and other
  front-ends could use that to avoid using the
  shaderSpiCsRegAllocFragmentation workaround on gfx705.

* The "TongaPro" variant of gfx802 is now split out into gfx805.
  TongaPro has a faster 64-bit shift than its former friends in gfx802,
  and a subtarget feature could be set up for that to take advantage of
  it. This commit does not make that change; it just adds the target.

V2: Add clang changes. Put TargetParser list in order.
V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,
    so fix the GPUKind order.

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

Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-10 17:22:22 +01:00
Evandro Menezes 5d6d8a2769 [RISCV] Add SiFive cores to the CPU option
Add the SiFive cores E76 and U74 using the SiFive 7 series microarchitecture.

Differential Revision: https://reviews.llvm.org/D88759
2020-10-05 15:50:57 -05:00
Roman Lebedev 03bd5198b6
[OldPM] Pass manager: run SROA after (simple) loop unrolling
I have stumbled into this pretty accidentally, when rewriting
some spaghetti-like code into something more structured,
which involved using some `std::array<>`s. And to my surprise,
the `alloca`s remained, causing about `+160%` perf regression.

https://llvm-compile-time-tracker.com/compare.php?from=bb6f4d32aac3eecb51909f4facc625219307ee68&to=d563e66f40f9d4d145cb2050e41cb961e2b37785&stat=instructions
suggests that this has geomean compile-time cost of `+0.08%`.

Note that D68593 / cecc0d27ad
already did this chage for NewPM, but left OldPM in a pessimized state.

This fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40011 | PR40011 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=42794 | PR42794 ]] and probably some other reports.

Reviewed By: nikic, xbolva00

Differential Revision: https://reviews.llvm.org/D87972
2020-10-04 11:53:50 +03:00
Nathan Lanza 14f6bfcb52 [clang] Implement objc_non_runtime_protocol to remove protocol metadata
Summary:
Motivated by the new objc_direct attribute, this change adds a new
attribute that remotes metadata from Protocols that the programmer knows
isn't going to be used at runtime. We simply have the frontend skip
generating any protocol metadata entries (e.g. OBJC_CLASS_NAME,
_OBJC_$_PROTOCOL_INSTANCE_METHDOS, _OBJC_PROTOCOL, etc) for a protocol
marked with `__attribute__((objc_non_runtime_protocol))`.

There are a few APIs used to retrieve a protocol at runtime.
`@protocol(SomeProtocol)` will now error out of the requested protocol
is marked with attribute. `objc_getProtocol` will return `NULL` which
is consistent with the behavior of a non-existing protocol.

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D75574
2020-10-02 17:35:50 -04:00
Jan Korous 6fd8c69049 [clang] Update warning-wall.c test
Follow-up to 1e86d637eb4f:
[clang] Selectively ena/disa-ble format-insufficient-args warning
2020-09-28 17:19:51 -07:00
Jan Korous 1e86d637eb [clang] Selectively ena/disa-ble format-insufficient-args warning
Differential Revision: https://reviews.llvm.org/D87176
2020-09-28 16:24:50 -07:00
Evandro Menezes a000580a89 [RISCV] Update driver tests
Add the RISC-V Bullet core to the driver tests.
2020-09-25 18:36:53 -05:00
Saleem Abdulrasool 296d8832a3 Sema: add support for `__attribute__((__swift_newtype__))`
Add the `swift_newtype` attribute which allows a type definition to be
imported into Swift as a new type.  The imported type must be either an
enumerated type (enum) or an object type (struct).

This is based on the work of the original changes in
8afaf3aad2

Differential Revision: https://reviews.llvm.org/D87652
Reviewed By: Aaron Ballman
2020-09-24 15:17:35 +00:00
Fangrui Song 9087209314 [Driver] Add disabled-by-default -Wuse-ld-path for the deprecation warning for -fuse-ld=/abs/path
The warning is currently not under a -W option, so it cannot be suppressed.
This is annoying for the widespread build system Bazel when specifying the path to gold
cdd0c3cdba

I have notified them about using --ld-path= forwards
https://github.com/bazelbuild/bazel/pull/8580#issuecomment-694321543
but we have to give some transitional period.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D87837
2020-09-19 15:49:44 -07:00
Saleem Abdulrasool 7d26d6a1b0 Sema: add support for `__attribute__((__swift_bridged_typedef__))`
Extend the semantic attributes that clang processes for Swift to include
`swift_bridged_typedef`.  This attribute enables typedefs to be bridged
into Swift with a bridged name.

This is based on the work of the original changes in
8afaf3aad2

Differential Revision: https://reviews.llvm.org/D87396
Reviewed By: Aaron Ballman
2020-09-15 20:15:34 +00:00
Saleem Abdulrasool 916b434035 Sema: add support for `__attribute__((__swift_objc_members__))`
This adds the `__swift_objc_members__` attribute to the semantic
analysis.  It allows for annotating ObjC interfaces to provide Swift
semantics indicating that the types derived from this interface will be
back-bridged to Objective-C to allow interoperability with Objective-C
and Swift.

This is based on the work of the original changes in
8afaf3aad2

Differential Revision: https://reviews.llvm.org/D87395
Reviewed By: Aaron Ballman, Dmitri Gribenko
2020-09-14 15:24:41 +00:00
Saleem Abdulrasool f5ab5b20fb Sema: add support for `__attribute__((__swift_error__))`
Introduce a new attribute that is used to indicate the error handling
convention used by a function.  This is used to translate the error
semantics from the decorated interface to a compatible Swift interface.

The supported error convention is one of:
- none: no error handling
- nonnull_error: a non-null error parameter indicates an error signifier
- null_result: a return value of NULL is an error signifier
- zero_result: a return value of 0 is an error signifier
- nonzero_result: a non-zero return value is an error signifier

Since this is the first of the attributes needed to support the semantic
annotation for Swift, this change also includes the necessary supporting
infrastructure for a new category of attributes (Swift).

This is based on the work of the original changes in
8afaf3aad2

Differential Revision: https://reviews.llvm.org/D87331
Reviewed By: John McCall, Aaron Ballman, Dmitri Gribenko
2020-09-11 21:20:38 +00:00