mathstuf wrote:
It was suggested to avoid "thin" and "fat" terminology (I started using it with
LTO as a precedent for the terms), but I suppose something more descriptive
could be selected.
https://github.com/llvm/llvm-project/pull/71622
___
cfe-com
mathstuf wrote:
I'll also note that my prior usage was in reference to embedding transitive BMI
references in the BMI, not about including function definitions.
https://github.com/llvm/llvm-project/pull/71622
___
cfe-commits mailing list
cfe-commits@l
mathstuf wrote:
> Since there is no meaningful review opinions here, let's continue it in a new
> and clean PR: https://github.com/llvm/llvm-project/pull/75894
Note that this leaves behind all who have hit "Subscribe" on this PR to keep
tabs on things (I wish Github provided a way to mark-as-d
mathstuf wrote:
> Sorry for that. But I think it may not be a big deal since people who still
> want to take an eye this can made it by clicking two times simply.
The timing is also unfortunate as some may have already gone on vacation and
will miss updates until they return. Anyways, what's d
@@ -2164,6 +2164,12 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
return false;
}
+ if (C.getArgs().hasArg(options::OPT_print_library_module_manifest_path)) {
+llvm::outs() << "module: ="
mathstuf wrote:
I'd like there to be some dist
@@ -2164,6 +2164,12 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
return false;
}
+ if (C.getArgs().hasArg(options::OPT_print_library_module_manifest_path)) {
+llvm::outs() << "module: ="
mathstuf wrote:
I suppose that's good enough;
mathstuf wrote:
> ClangGetUsedFilesFromModulesPlugin
This has a hole where if a currently-unused file is not listed, but it is
changed in such a way that it now matters (e.g., it changes include order,
adds/removes includes, etc.), we need to recompile consumers.
> what happens if someone add
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix
> real-world bugs that would be caused if Clang becomes overly pedantic by
> default here. And the probability of introducing real-world bugs is
> essentially zero.
FWIW,
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
return std::nullopt;
}
+ virtual std::vector getAllFilesInProjectOf(PathRef File) const {
mathstuf wrote:
`compile_commands.json` probably isn't the best place for it as it cannot be
filled out at t
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
return std::nullopt;
}
+ virtual std::vector getAllFilesInProjectOf(PathRef File) const {
mathstuf wrote:
Probably easiest to see it by the writer code
[here](https://gitlab.kitware.com/ben.boeckel/
https://github.com/mathstuf edited
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mathstuf edited
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mathstuf edited
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
mathstuf wrote:
> Nice find. That's kind of horrifying.
Indeed. CMake's old "guess the extension" behavior was always a…fun thing to
deal with. Alas, this emergent behavior was unknown at the time and a straight
fix is likely to break other projects :( . Plus it's not likely we'll get
patched
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
mathstuf wrote:
> Really we would have to remove the preprocessor from C++ to be able to get
> away from this.
:clap: Maybe we can get a magic `-fno-preprocess` flag to say "I use no
preprocessor shenanigans" and make always-compatible BMIs? Maybe then we could
adapt the Fortran/ASM conventio
mathstuf wrote:
Should this be backported to older supported releases as well? (FWIW, I think
so.)
https://github.com/llvm/llvm-project/pull/122370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
23 matches
Mail list logo
