History log of /llvm-project/clang/test/CXX/module/basic/basic.link/module-declaration.cpp (Results 1 – 4 of 4)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# c91e8527 22-Jul-2024 yronglin <yronglin777@gmail.com>

Revert "[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros" (#99838)

Reverts llvm/llvm-project#90574


# e77a01d7 20-Jul-2024 yronglin <yronglin777@gmail.com>

[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros (#90574)

This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convolute

[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros (#90574)

This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convoluted state
machines in module name lexical analysis.

---------

Signed-off-by: yronglin <yronglin777@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, 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, 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
# 57833636 24-Feb-2023 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Deprecate to load C++20 Modules eagerly

Close https://github.com/llvm/llvm-project/issues/60824

The form -fmodule-file=<path-to-BMI> will load modules eagerly and the
form -fmodul

[C++20] [Modules] Deprecate to load C++20 Modules eagerly

Close https://github.com/llvm/llvm-project/issues/60824

The form -fmodule-file=<path-to-BMI> will load modules eagerly and the
form -fmodule-file=<module-name>=<path-to-BMI> will load modules lazily.
The inconsistency adds many additional burdens to the implementations.
And the inconsistency looks not helpful and necessary neither. So I want
to deprecate the form -fmodule-file=<path-to-BMI> for named modules.
This is pretty helpful for us (the developers).

Does this change make any regression from the perspective of the users?

To be honest, yes. But I think such regression is acceptable. Here is
the example:

```
// M.cppm
export module M;
export int m = 5;

// N.cpp
// import M; // woops, we forgot to import M.
int n = m;
```

In the original version, the compiler can diagnose the users to import
`M` since the compiler have already imported M. But in the later style,
the compiler can only say "unknown identifier `m`".

But I think such regression doesn't make a deal since it only works if
the user put `-fmodule-file=M.pcm` in the command line. But how can the
user put `-fmodule-file=M.pcm` in the command line without `import M;`?
Especially currently such options are generated by build systems. And
the build systems will only generate the command line from the source
file.

So I think this change is pretty pretty helpful for developers and
almost innocent for users and we should accept this one.

I'll add the release notes and edit the document after we land this.

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

show more ...


Revision tags: llvmorg-16.0.0-rc3
# d54888a3 16-Feb-2023 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[Modules] Refactor modules-ts tests to use standard c++ modules

We're going to remove the support for modules-ts. But there are a lot of
tests which uses -fmodules-ts. We shouldn't remove them simpl

[Modules] Refactor modules-ts tests to use standard c++ modules

We're going to remove the support for modules-ts. But there are a lot of
tests which uses -fmodules-ts. We shouldn't remove them simply. This
patch refactor these tests to use standard c++ modules.

show more ...