vsapsai wrote:
I'll be busy during WWDC week too, so no real changes are expected in the next
2 weeks.
https://github.com/llvm/llvm-project/pull/138227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
vsapsai wrote:
> Thanks a lot, I am sorry for misreading or misunderstanding your comments
> too. I hope we can put this behind ourselves.
Appreciate the understanding.
> [skip the technical description]
Thanks for the explanation, it gives a lot of food for thought. Still building
a mental
https://github.com/vsapsai approved this pull request.
Discussed it with Cyndy more and I think that the trade-off is
* "AST file" is easier to search for as it is more specific
* "AST file" can be more confusing for non-compiler developers as they aren't
required to work with and to know about
vsapsai wrote:
I think in the second case we usually use "AST file" to lump together .pcm and
.pch.
https://github.com/llvm/llvm-project/pull/142161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
vsapsai wrote:
Right now I don't have a strong opinion about the specific terminology. Though
it might change as I think about it more.
What I do have a strong opinion about is mentioning a specific file. In the
first quick pass it looks like we do that already, e.g., "please rebuild
precompi
vsapsai wrote:
How natural is it to assume that "precompiled file" is the same-ish as
"compiled file" aka "object file"? I'm wary of making users pay attention to
such details. "Precompiled header" is an existing term, so I'm fine using it.
But it is worth considering what are the differences
vsapsai wrote:
What about the approach to provide all_textual.pcm to use.cpp and for clang to
find foo.h in all_textual.pcm? It doesn't work right now but I'm not sure that
it shouldn't (there can be good reasons why it shouldn't work, tbh).
https://github.com/llvm/llvm-project/pull/138227
___
vsapsai wrote:
I think I understand the logic behind your approach.
* Access between headers is enforced through decl-use, so you cannot access
headers from a target that's not your direct dependency.
* But some headers shouldn't be accessed outside of a target [regardless of the
dependencies],
vsapsai wrote:
Do you include proto headers directly or through the wrapper headers?
Are there any important macros in proto headers?
Do you need to abuse macros to get something out of proto headers? Kinda like
`#define private public` but more realistic.
My initial reaction is to offer a so
vsapsai wrote:
> Back to the original issue.
Do you control the module map that specifies a header as private? Does it need
to stay private?
Personally, to me it looks like a bug that a private header is getting picked
up [somewhat accidentally]. I'm not planning to fix this bug, just that re
vsapsai wrote:
> It is concerning to me that we as a company are given **a week** to adjust to
> the change and there is no discussion either about alternative approaches or
> the scale of the changes needed to support this. We do rely on all kinds of
> weird behaviors and side effects in Clan
vsapsai wrote:
Ok, I'm going to revert the change to help you out. But I'm going to re-land it
in a week or when you are ready, whichever comes first.
There was no indication there is anything wrong with the change or if the issue
is wide-spread. And if a single company relies on an existing s
Author: Volodymyr Sapsai
Date: 2025-05-22T18:34:30-07:00
New Revision: 720014f70841f0284d21ef8100c406d6c864ac9c
URL:
https://github.com/llvm/llvm-project/commit/720014f70841f0284d21ef8100c406d6c864ac9c
DIFF:
https://github.com/llvm/llvm-project/commit/720014f70841f0284d21ef8100c406d6c864ac9c.di
vsapsai wrote:
> @vsapsai I guess, it's a good sign? :) Do you see how our use case can be
> supported by a trivial and low-risk forward fix? If not, I'd insist on a
> revert before we can figure out the way forward. We can run this sort of a
> change through our testing before it relands, and
vsapsai wrote:
Interesting, changing `private header "wrap_foo.h"` to `header "wrap_foo.h"` in
`b.wrap_foo` stops reproducing the error. I'm not sure it guarantees
> whenever resolving module for the header, pick one that has the header as
> modular over textual.
But seems we are closer to th
vsapsai wrote:
It's weird that clang picked `b.wrap_foo` for "wrap_foo.h" as it is specified
as `private header`. To me it looks like circumventing "use of private header
from outside its module [-Wprivate-header]".
https://github.com/llvm/llvm-project/pull/138227
_
vsapsai wrote:
> I know what we do is cheesy and we might need to reconsider how to approach
> it, but this is a breaking change and it would be great to find a resolution
> for it before committing to the new behavior. Could we revert this while we
> discuss the potential ways out of it?
Wha
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/138227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
Thanks for the review!
https://github.com/llvm/llvm-project/pull/138227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/138358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/138358
Restore the behavior existing prior to
fe2eefc4718f57e1753f7bd51c158fc03d70b34f. Make reporting of unevaluated
directive source range more consistent and with fewer assumptions. In case of a
failed evaluation
vsapsai wrote:
The change for `exclude` headers was done in
040e12662a674e2ebfc93f86a70eddb7d6fc76da.
https://github.com/llvm/llvm-project/pull/138227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/138227
According to the documentation
> A header declaration that does not contain `exclude` nor `textual` specifies
> a header that contributes to the enclosing module.
Which means that `exclude` and `textual` header
https://github.com/vsapsai approved this pull request.
Ok to merge after fixing the formatting.
https://github.com/llvm/llvm-project/pull/137675
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
vsapsai wrote:
> Not really, using `LangOptions` directly instead of
> `std::unique_ptr` allows reassignment too. I chose
> `std::unique_ptr` to:
>
> * prevent increase of `ASTUnit` size,
> * avoid unconditional initialization of `ASTUnit::LangOpts` in the
> constructor (which would be an unn
https://github.com/vsapsai approved this pull request.
https://github.com/llvm/llvm-project/pull/137227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai commented:
Also looks like [this
assert](https://github.com/llvm/llvm-project/blob/14469a8726fc1d038f41c7e3e29a84ec8f52d013/clang/include/clang/Frontend/ASTUnit.h#L472)
doesn't serve its value anymore
```c++
const LangOptions &getLangOpts() const {
assert(LangOp
vsapsai wrote:
> The `unique_ptr` in `ASTUnit` always stores a **copy** of the `shared_ptr` in
> `CompilerInvocation`.
And we need `unique_ptr` in `ASTUnit` instead of a direct value so we can
change LangOpts in `ASTUnit::Parse`?
https://github.com/llvm/llvm-project/pull/137675
__
vsapsai wrote:
Does the described test case look like a build system problem? In my
understanding at step 4 we should have re-scanned B to know that we need some
B'.pcm depending on A-2.pcm. Regardless of the answer I don't want to block the
change as it is still an improvement. Just thinking
vsapsai wrote:
> > What would happen if both A-1.pcm and A-2.pcm are built for the same files
> > (e.g., from Sysroot) but have different file names? Not saying it is a
> > valid use case to support, just curious what would happen.
>
> I tried this, where basically `A-1.pcm` is built again but
@@ -0,0 +1,62 @@
+/// This tests the expected error case when there is a mismatch between the
pcm dependencies passed in
+/// the command line with `fmodule-file` and whats encoded in the pcm.
+
+/// The steps are:
+/// 1. Build module (A-1) with no dependencies.
+/// 2. Build
https://github.com/vsapsai commented:
What would happen if both A-1.pcm and A-2.pcm are built for the same files
(e.g., from Sysroot) but have different file names? Not saying it is a valid
use case to support, just curious what would happen.
https://github.com/llvm/llvm-project/pull/136612
__
https://github.com/vsapsai edited
https://github.com/llvm/llvm-project/pull/136612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,62 @@
+/// This tests the expected error case when there is a mismatch between the
pcm dependencies passed in
+/// the command line with `fmodule-file` and whats encoded in the pcm.
+
+/// The steps are:
+/// 1. Build module (A-1) with no dependencies.
+/// 2. Build
@@ -0,0 +1,62 @@
+/// This tests the expected error case when there is a mismatch between the
pcm dependencies passed in
+/// the command line with `fmodule-file` and whats encoded in the pcm.
+
+/// The steps are:
+/// 1. Build module (A-1) with no dependencies.
+/// 2. Build
@@ -3311,12 +3314,11 @@ ASTReader::ReadControlBlock(ModuleFile &F,
SignatureBytes.end());
Blob = Blob.substr(ASTFileSignature::size);
-if (ImportedFile.empty()) {
- // Use BaseDirectoryAsWritten to ens
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/135887
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai updated
https://github.com/llvm/llvm-project/pull/135887
>From d944252ce2f08d1522f7297e4d7f9a7b730db180 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Tue, 15 Apr 2025 16:34:47 -0700
Subject: [PATCH 1/2] [Modules] Fix the inconsistency of which `Decl` should be
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/135471
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
cc @zygoloid as he has touched this code 10 years ago.
https://github.com/llvm/llvm-project/pull/135887
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -224,6 +224,7 @@ class ASTWriter : public ASTDeserializationListener,
/// discovery) and start at 2. 1 is reserved for the translation
/// unit, while 0 is reserved for NULL.
llvm::DenseMap DeclIDs;
+ // TMP: ^ DeclIDs type for reference
vsapsai wrote
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/135887
Fixes the assertion failure
> Assertion failed: (DeclIDs.contains(D) && "Declaration not emitted!"),
> function getDeclID, file ASTWriter.cpp, line 6873.
We prepare to serialize a `Decl` by adding it to `DeclID
@@ -2419,6 +2422,9 @@ namespace {
// declarations it needs.
++NumIdentifierLookupHits;
Found = *Pos;
+ if (Trait.hasMoreInformationInDependencies())
+// Look for the identifier in extra modules as they contain more info.
+return false;
---
https://github.com/vsapsai updated
https://github.com/llvm/llvm-project/pull/135471
>From cf55ae79e984cd5b046e4d78fd9d75d5f7c2d76e Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Fri, 11 Apr 2025 20:10:46 -0700
Subject: [PATCH 1/2] [Modules] Fix an identifier hiding a function-like macro
@@ -3871,7 +3874,8 @@ class ASTIdentifierTableTrait {
if (isInterestingIdentifier(II, MacroOffset)) {
DataLen += 2; // 2 bytes for builtin ID
DataLen += 2; // 2 bytes for flags
- if (MacroOffset)
+ if (MacroOffset || (II->hasMacroDefinition() &&
+
vsapsai wrote:
By the way, looked at the other tests in Modules directory and think that the
test should start with "macro-" for consistency. Probably something like
"macro-identifier-hiding.c" as we have "macro-hiding.cpp" already.
https://github.com/llvm/ll
vsapsai wrote:
> Thanks! Does the pr fix https://bugs.llvm.org//show_bug.cgi?id=32670
Nope. The test case in #32017 is still failing. I believe it is a different
issue as we don't have any identifiers with the same names as macros. And seems
like the behavior wasn't affected by d79514e24b4da11
vsapsai wrote:
cc @bcardosolopes @vgvassilev as participants of the original bug discussion.
https://github.com/llvm/llvm-project/pull/135471
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/135471
We emit a macro definition only in a module defining it. But it means that if
another module has an identifier with the same name as the macro, the users of
such module won't be able to use the macro anymore.
@@ -2990,26 +2996,18 @@ static bool sdkSupportsBuiltinModules(
return false;
VersionTuple SDKVersion = SDKInfo->getVersion();
- switch (TargetPlatform) {
+ switch (SDKInfo->getOS()) {
// Existing SDKs added support for builtin modules in the fall
// 2024 major re
@@ -62,6 +63,28 @@ DarwinSDKInfo::RelatedTargetVersionMapping::parseJSON(
Min, Max, MinValue, MaximumDeploymentTarget, std::move(Mapping));
}
+static llvm::Triple::OSType parseOS(const llvm::json::Object &Obj) {
+ // The CanonicalName is the Xcode platform, a version, a
https://github.com/vsapsai commented:
I've realized that the test doesn't have to be Objective-C, the failure is
reproducible in C. Curiously, we aren't hitting the assertion in
C++/Objective-C++ but I don't know why.
I wanted to try defining the enums in different scopes (e.g. in a struct) an
vsapsai wrote:
In general, personally I quite like the idea of removing decls from the scope.
Though I think when I've tried to do so [in a different context], there were
some problems. I'll try to find what I was doing and why it wasn't working.
It's not a blocker for your change but it can b
vsapsai wrote:
That crash looks pretty annoying, thanks for looking into this issue and
debugging it.
Can you trigger the crash without `-ast-dump-all`? If there is a way to detect
a faulty behaviour without verifying the internal compiler state, it is more
reliable and less fragile to do it
https://github.com/vsapsai commented:
Overall the change makes sense and now `ModuleMap` works more like semantic
analysis after the module map parsing.
Didn't really delve into the parsing code and didn't compare the
implementations side-by-side. Relying on the tests and expect most of the co
@@ -0,0 +1,141 @@
+//===- ModuleMapFile.h - Parsing and representation -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -1575,305 +1494,45 @@ namespace clang {
/// 'textual' to match the original intent.
llvm::SmallPtrSet UsesRequiresExcludedHack;
-/// Consume the current token and return its location.
-SourceLocation consumeToken();
-
-/// Skip tokens until we reach the
@@ -0,0 +1,141 @@
+//===- ModuleMapFile.h - Parsing and representation -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/vsapsai edited
https://github.com/llvm/llvm-project/pull/119740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/122034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
Test failure
"LLVM.tools/llvm-gsymutil/ARM_AArch64/macho-merged-funcs-dwarf.yaml" is
unrelated to this change.
https://github.com/llvm/llvm-project/pull/122034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/122034
Add a new file to the module map and remove 2 missing files (migrated from .def
to .td).
>From cc9d4ebe3880810c8325f1fd6c7b9e2a49f2fe74 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Tue, 7 Jan 2025 17:
vsapsai wrote:
I don't know if we have a test for it but I've realized there are cases where
you can have a legitimate double colon in Objective-C. For example,
```objective-c
@interface NSObject
@end
@implementation NSObject
- (void)performSelector:(SEL)selector {}
- (void)double:(int)firstAr
vsapsai wrote:
Sorry for the delay. Will need to look at the change in a debugger.
https://github.com/llvm/llvm-project/pull/114240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
How does it work in Objective-C++? I don't know even if we have a test but hope
we do.
https://github.com/llvm/llvm-project/pull/119908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/vsapsai approved this pull request.
https://github.com/llvm/llvm-project/pull/112452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
> > Have you checked the performance for incremental builds?
>
> I haven't, since I believe this change doesn't affect incremental builds at
> all.
Fair enough. I was thinking that you can achieve the same improvement by using
some contentionless-update-mtime function. But I ha
https://github.com/vsapsai commented:
I think the change makes sense. For example, for just-built .o files we assume
they are valid and up-to-date, and don't need any extra verification.
As far as I understand, your change helps with the clean builds. And I believe
incremental builds can still
@@ -4905,6 +4905,10 @@ ASTFileSignature ASTWriter::WriteAST(Sema &SemaRef,
StringRef OutputFile,
this->BaseDirectory.clear();
WritingAST = false;
+
+ if (WritingModule)
+updateModuleTimestamp(OutputFile);
vsapsai wrote:
Don't have a strong opinion a
https://github.com/vsapsai edited
https://github.com/llvm/llvm-project/pull/112452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/110780
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
CI error
```
Traceback (most recent call last):
File
"/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-r8xzr-1/llvm-project/github-pull-requests/libcxx/utils/generate_iwyu_mapping.py",
line 92, in
main(sys.argv[1:])
File
"/var/lib/buildkite-agent/builds/linux-56-59b8f
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/110780
None
>From 030597a499d59b860cd14a6e5ba69b93a4b30290 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Tue, 1 Oct 2024 18:46:04 -0700
Subject: [PATCH] [Modules] Mark CFProtectionOptions.def as a textual head
https://github.com/vsapsai approved this pull request.
https://github.com/llvm/llvm-project/pull/110724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai approved this pull request.
Thanks for fixing these!
https://github.com/llvm/llvm-project/pull/107654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
Formatting change was #102484.
https://github.com/llvm/llvm-project/pull/101413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/102484
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/102484
Fix formatting for fdf8e3e31103bc81917cdb27150877f524bb2669.
>From 4083dcf794e2a3d27966090e955433361b733ff8 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Thu, 8 Aug 2024 11:51:53 -0300
Subject: [PATCH]
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/101413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -130,7 +130,7 @@ class ASTReaderListener {
///
/// \returns true to indicate the options are invalid or false otherwise.
virtual bool ReadLanguageOptions(const LangOptions &LangOpts,
- bool Complain,
+
@@ -0,0 +1,84 @@
+// Check how builtins using varargs behave with the modules.
+
+// REQUIRES: x86-registered-target
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -triple x86_64-apple-darwin \
vsapsai wrote:
The issue is reproducible on x86_6
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/101762
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/101762
Fix the false warning
> incompatible pointer types passing 'va_list' (aka '__builtin_va_list') to
> parameter of type 'struct __va_list_tag *' [-Wincompatible-pointer-types]
The warning is wrong because both in
vsapsai wrote:
Looks like need something like `// REQUIRES: x86-registered-target` in the
test. But still need to check the correct approach in other tests.
https://github.com/llvm/llvm-project/pull/100837
___
cfe-commits mailing list
cfe-commits@list
https://github.com/vsapsai updated
https://github.com/llvm/llvm-project/pull/101413
>From c474bcdc5155d3ca9f9d219444b70e6c0ba43a28 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Wed, 31 Jul 2024 14:13:47 -0700
Subject: [PATCH 1/3] [Modules][Diagnostic] Mention which AST file's options
d
https://github.com/vsapsai updated
https://github.com/llvm/llvm-project/pull/101413
>From c474bcdc5155d3ca9f9d219444b70e6c0ba43a28 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Wed, 31 Jul 2024 14:13:47 -0700
Subject: [PATCH 1/2] [Modules][Diagnostic] Mention which AST file's options
d
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/100837
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
> LGTM.
Thanks for the review!
https://github.com/llvm/llvm-project/pull/100837
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -130,7 +130,7 @@ class ASTReaderListener {
///
/// \returns true to indicate the options are invalid or false otherwise.
virtual bool ReadLanguageOptions(const LangOptions &LangOpts,
- bool Complain,
+
vsapsai wrote:
> I'd suggest keeping this PR and the resulting commit free of any formatting
> changes and then commit the results from `clang-format` as a separate commit.
Will do that.
> After #101280 I had the impression that we're trying to be very precise about
> reporting whether an AST
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/101280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
I have more similar improvements when a diagnostic claims a mismatch is in PCH
file while it is in a module file. Those would be separate PR(s) as the code
change is quite different.
https://github.com/llvm/llvm-project/pull/101280
___
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/101280
You can provide more than one AST file as an input. Emit a path for a file with
a problem, so you can disambiguate between multiple files.
rdar://65005546
>From c115a7f6b3e36682bfdd9768ab7969e0f11489bb Mon Sep
https://github.com/vsapsai created
https://github.com/llvm/llvm-project/pull/100837
Fix the false warning
> incompatible pointer types passing 'va_list' (aka '__builtin_va_list') to
> parameter of type 'struct __va_list_tag *' [-Wincompatible-pointer-types]
The warning is wrong because both in
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/15
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
Failed test is "Profile-x86_64 :: check-same-common-code.test", the same as
failed in #100011 for unrelated reasons.
https://github.com/llvm/llvm-project/pull/15
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/vsapsai updated
https://github.com/llvm/llvm-project/pull/15
>From 8566865fd55a4634414f339a39c045aac637f374 Mon Sep 17 00:00:00 2001
From: Volodymyr Sapsai
Date: Mon, 22 Jul 2024 15:40:15 -0700
Subject: [PATCH 1/2] [Modules] Don't search for modulemaps in the immediate
s
https://github.com/vsapsai closed
https://github.com/llvm/llvm-project/pull/100011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vsapsai wrote:
Failed test is unrelated "Profile-x86_64 :: check-same-common-code.test".
https://github.com/llvm/llvm-project/pull/100011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
vsapsai wrote:
Noticed inconsistencies after #15 as I have pre-release Xcode locally.
https://github.com/llvm/llvm-project/pull/100011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
1 - 100 of 330 matches
Mail list logo
