|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
| #
d33937b6 |
| 05-May-2024 |
Fangrui Song <i@maskray.me> |
[test] %clang_cc1: remove redundant actions
ParseFrontendArgs takes the last OPT_Action_Group option. The other
actions are overridden.
|
| #
7e59223a |
| 05-May-2024 |
Fangrui Song <i@maskray.me> |
[test] %clang_cc1: remove redundant actions
ParseFrontendArgs takes the last OPT_Action_Group option. The other
actions are overridden.
|
| #
7c1d9b15 |
| 05-May-2024 |
Fangrui Song <i@maskray.me> |
[test] %clang_cc1: remove redundant actions
|
| #
c5de4dd1 |
| 05-May-2024 |
Fangrui Song <i@maskray.me> |
[test] %clang_cc1 -emit-llvm: remove redundant -S
And replace -emit-llvm -o - with -emit-llvm-only
|
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
| #
dc4e85bd |
| 12-Jan-2024 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Remove hardcoded path to imported module in BMIs
Close https://github.com/llvm/llvm-project/issues/62707
As we discussed before, we'll forbid the use of implicit generated path
fo
[C++20] [Modules] Remove hardcoded path to imported module in BMIs
Close https://github.com/llvm/llvm-project/issues/62707
As we discussed before, we'll forbid the use of implicit generated path
for C++20 modules. And as I mentioned in
https://github.com/llvm/llvm-project/issues/62707, we've emitted a
warning for clang17 and we'll make it a hard error in clang18. And the
patch addresses the decision.
show more ...
|
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5 |
|
| #
6e4f870a |
| 03-Jun-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
re-land [C++20][Modules] Introduce an implementation module.
We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for
re-land [C++20][Modules] Introduce an implementation module.
We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).
This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.
Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).
Differential Revision: https://reviews.llvm.org/D126959
show more ...
|
| #
074f6fd6 |
| 27-Mar-2023 |
Mitch Phillips <31459023+hctim@users.noreply.github.com> |
Revert "[C++20][Modules] Introduce an implementation module."
This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.
Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(t
Revert "[C++20][Modules] Introduce an implementation module."
This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.
Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(the original phabricator review) for more info.
show more ...
|
| #
c6e98237 |
| 03-Jun-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Introduce an implementation module.
We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cas
[C++20][Modules] Introduce an implementation module.
We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).
This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.
Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).
Differential Revision: https://reviews.llvm.org/D126959
show more ...
|
| #
b76da14b |
| 19-Sep-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++] [Modules] Generate the initializer for modules if we compile a
module unit directly
Previously we lack a test which ensures that the module unit will
generate initializer if it is compiled dir
[C++] [Modules] Generate the initializer for modules if we compile a
module unit directly
Previously we lack a test which ensures that the module unit will
generate initializer if it is compiled directly (instead of from a pcm
file). Now we add the test back.
show more ...
|
| #
298d08df |
| 19-Sep-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] Move the position of CodeGen/module-initializer*.cpp
Previsouly the module-initializer*.cpp lives in the CodeGen dir instead
of CodeGenCXX dir, which is not consistency with other tests since
[NFC] Move the position of CodeGen/module-initializer*.cpp
Previsouly the module-initializer*.cpp lives in the CodeGen dir instead
of CodeGenCXX dir, which is not consistency with other tests since
modules are features for C++.
show more ...
|