[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-05-06 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/90676 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-05-02 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/90676 >From 12964a3632d81d500b76c1a8a5c83a6367c66e00 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 30 Apr 2024 15:16:38 -0700 Subject: [PATCH] [clang][modules] stdarg.h and stddef.h shouldn't

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-05-02 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > I think I like this as a solution, although I wonder if > __stdarg_guard_macro.h would be a better name. The name now somewhat implies > that it contains the macros that stddef and stdarg define. But the macros don't actually guard anything. _macro isn't the best

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-05-02 Thread Ian Anderson via cfe-commits
@@ -15,9 +15,11 @@ const HeaderMapCollector::RegexHeaderMap *getSTLPostfixHeaderMap() { static const HeaderMapCollector::RegexHeaderMap STLPostfixHeaderMap = { {"include/__stdarg___gnuc_va_list.h$", ""}, {"include/__stdarg___va_copy.h$", ""}, +

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-05-01 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/90676 >From 54652504cb9e56c3972270c43cc4ee8d613979b4 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 30 Apr 2024 15:16:38 -0700 Subject: [PATCH] [clang][modules] stdarg.h and stddef.h shouldn't

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-04-30 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/90676 >From 052dfeb8d94971dadfa65147f79d5fa37910b0e0 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 30 Apr 2024 15:16:38 -0700 Subject: [PATCH] [clang][modules] stdarg.h and stddef.h shouldn't

[clang] [clang-tools-extra] [llvm] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-04-30 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/90676 >From 8d8756f00297e90e0b1125d2a78d3f41c9aae6a7 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 30 Apr 2024 15:16:38 -0700 Subject: [PATCH] [clang][modules] stdarg.h and stddef.h shouldn't

[clang] [clang][modules] stdarg.h and stddef.h shouldn't directly declare anything (PR #90676)

2024-04-30 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/90676 stdarg.h and especially stddef.h are textual and so everything they declare gets precompiled into all of their clients' pcm files. They shouldn't directly declare anything though, their purpose is to

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader sets textual headers' HeaderFileInfo non-external when it shouldn't (PR #89005)

2024-04-25 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: >From Jan: > Maybe we can add the number of external HeaderFileInfos to > HeaderSearch::PrintStats() and have a test that checks for it. > The flag to enable that output is -show-stats I think. https://github.com/llvm/llvm-project/pull/89005

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader sets textual headers' HeaderFileInfo non-external when it shouldn't (PR #89005)

2024-04-22 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: I guess https://github.com/llvm/llvm-project/pull/89441 is the real issue that https://github.com/llvm/llvm-project/pull/83660 caused, but we should still fix this for correctness, even though I'm not sure what the visible consequence is of this bug.

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader sets textual headers' HeaderFileInfo non-external when it shouldn't (PR #89005)

2024-04-22 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader sets textual headers' HeaderFileInfo non-external when it shouldn't (PR #89005)

2024-04-22 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/89005 >From 45e7409a92546aab4cf8c79ce0ba40133e4dfe4c Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 16 Apr 2024 17:08:28 -0700 Subject: [PATCH] [clang][modules] HeaderSearch::MarkFileModuleHeader

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader sets textual headers' HeaderFileInfo non-external when it shouldn't (PR #89005)

2024-04-22 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)

2024-04-19 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > Is this a pre-existing issue, or did my patch change to make "each textual > > header gets a `HFI`"? > > My best understanding that your patch gave textual headers`HFI`s when the > module map was loaded, rather than when the header was included. This > shouldn't

[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)

2024-04-19 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > I updated the description of this PR, hopefully it makes more sense now. I > still need to investigate what goes wrong in > "Modules/preprocess-decluse.cpp". It seems that it assumes `%t/b.pcm` embeds > the information from "a.modulemap". Is this a pre-existing

[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)

2024-04-19 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > Hmm, this will probably only work if you compile `A` into a PCM and then > > pass it to `B`. This is not how "Modules/preprocess-decluse.cpp" is set up. > > In our case we always have a chain A <- B <- C. A.modulemap can be affecting > for B but should not be for

[clang] [clang][modules] Allow module maps with textual headers to be non-affecting (PR #89441)

2024-04-19 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder approved this pull request. I don't totally understand the change, but I don't see anything wrong with it! https://github.com/llvm/llvm-project/pull/89441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-19 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > Unfortunately with this patch I'm still seeing the same > source-location-exhausted error. I'm going to try to understand why... Damn I really thought that was going to be the one. If you have any way I could reproduce or better write a test that would be great.

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-18 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > Ok _this_ one should fix the logic I think. @ilya-biryukov can you give this > a try please? @ilya-biryukov sorry to ping you again, just nobody else knows how to test this. https://github.com/llvm/llvm-project/pull/89005

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
@@ -1313,6 +1313,14 @@ OptionalFileEntryRef HeaderSearch::LookupSubframeworkHeader( // File Info Management. //===--===// +static bool +headerFileInfoModuleBitsMatchRole(const HeaderFileInfo *HFI, +

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > Also note that `ASTWriter` uses this logic in couple of places to avoid > serializing unrelated headers: > > ```c++ > if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader)) > continue; > ``` > > Since textual headers from other modules have

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > As a test, maybe you could probe the resulting PCM with `-module-file-info`. What would I be looking for? Presumably the problem is we import the same module twice but fail to find the built pcm in the module cache and so we build it again? I don't know what else

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
@@ -84,7 +84,9 @@ struct HeaderFileInfo { LLVM_PREFERRED_TYPE(bool) unsigned isModuleHeader : 1; - /// Whether this header is a `textual header` in a module. + /// Whether this header is a `textual header` in a module. If a header is + /// textual in one module and

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Ok _this_ one should fix the logic I think. @ilya-biryukov can you give this a try please? https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/89005 >From 0ea2af8066f2fb307f3bd273cf34da82189af0ab Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 16 Apr 2024 17:08:28 -0700 Subject: [PATCH] [clang][modules] HeaderSearch::MarkFileModuleHeader

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
@@ -1313,6 +1313,14 @@ OptionalFileEntryRef HeaderSearch::LookupSubframeworkHeader( // File Info Management. //===--===// +static bool +headerFileInfoModuleBitsMatchRole(const HeaderFileInfo *HFI, +

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-17 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > @ilya-biryukov can you check that this fixes your running out of source > > location space problem please? > > Just tried it. The patch as is did not help. I've also tried changing the > previous line to `getExistingFileInfo(, /*WantExternal=*/false)` and it >

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-16 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: @ilya-biryukov can you check that this fixes your running out of source location space problem please? https://github.com/llvm/llvm-project/pull/89005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-16 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: I don't really know a great way to write a test for this. If someone could point me at a similar existing test or has an idea how to write a new test that would be much appreciated. https://github.com/llvm/llvm-project/pull/89005

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-16 Thread Ian Anderson via cfe-commits
@@ -1403,94 +1421,146 @@ bool HeaderSearch::isFileMultipleIncludeGuarded(FileEntryRef File) const { void HeaderSearch::MarkFileModuleHeader(FileEntryRef FE, ModuleMap::ModuleHeaderRole Role, bool

[clang] [clang][modules] HeaderSearch::MarkFileModuleHeader creates extra HeaderFileInfo, breaks PCM reuse (PR #89005)

2024-04-16 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/89005 HeaderSearch::MarkFileModuleHeader is no longer properly checking for no-changes, and so creates a new HeaderFileInfo for every `textual header`, causes PCM use to go ballistic. >From

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-16 Thread Ian Anderson via cfe-commits
@@ -1403,94 +1421,146 @@ bool HeaderSearch::isFileMultipleIncludeGuarded(FileEntryRef File) const { void HeaderSearch::MarkFileModuleHeader(FileEntryRef FE, ModuleMap::ModuleHeaderRole Role, bool

[clang] [Modules] Add -cc1 -flate-module-map-file to load module maps after PCMs (PR #88893)

2024-04-16 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: + @Bigcheese and @jansvoboda11 as I think they know this area of the code better https://github.com/llvm/llvm-project/pull/88893 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-16 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > To get back to my previous point about the semantics implemented by this > patch being unfortunate -- the upshot is that, now: > > ``` > #include > #define NDEBUG > #import > ``` It would be nice if we could make this work without modules too. `#pragma many` or

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-16 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Wall of text incoming... Sorry but our documentation in this area is poor, so I feel like I need to spell out the assumptions behind this change. First of all, this _should_ be a relatively minor change that should affect a very limited set of circumstances. 1. Only

[clang] [modules] allow use of ptrauth module from no_undeclared_includes system modules (PR #88432)

2024-04-12 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/88432 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > The end result should be that #imported and #pragma once-guarded files are > treated the same way as #ifndef-guarded files. While I don't necessarily disagree with that goal in principle, it wasn't true before this change either. There was already some special

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Also this change isn't trying to modify `#include` in any kind of way, _only_ `#import`. So it's quite intentional that your test behaves the same before and after. https://github.com/llvm/llvm-project/pull/83660 ___

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: I don't really think it's the same thing. The problem I'm trying to fix is that nobody knows when it's appropriate to use `#import` vs `#include`, and the unfortunate convention of Objective-C makes it impossible for header owners to indicate if they support being

[clang] [modules] allow use of ptrauth module from no_undeclared_includes system modules (PR #88432)

2024-04-12 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/88432 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] allow use of ptrauth module from no_undeclared_includes system modules (PR #88432)

2024-04-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Upstream from Apple, followup for https://github.com/llvm/llvm-project/pull/65996. Allows Apple's Darwin module to include ptrauth.h without declaring a `use`. https://github.com/llvm/llvm-project/pull/88432 ___ cfe-commits

[clang] allow use of ptrauth module from no_undeclared_includes system modules (PR #88432)

2024-04-12 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/88432 >From 88da8be7ed10f1ee8e7e992fdd59dce52456b2ce Mon Sep 17 00:00:00 2001 From: Alex Lorenz Date: Thu, 9 Jul 2020 15:10:49 -0700 Subject: [PATCH] [modules] allow use of ptrauth module from

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Wow that's a _ton_ of PCM files. Why are your headers `textual` if they're only meant to be included once? Do they need to inherit the includer's preprocessor environment or something like that? https://github.com/llvm/llvm-project/pull/83660

[clang] allow use of ptrauth module from no_undeclared_includes system modules (PR #88432)

2024-04-11 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/88432 None >From 43b007bfb184c6fdb5d802afca16af14e555b628 Mon Sep 17 00:00:00 2001 From: Alex Lorenz Date: Thu, 9 Jul 2020 15:10:49 -0700 Subject: [PATCH] allow use of ptrauth module from

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-11 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > It's definitely caused by that change, reverting it fixes the failure. > > We use module maps so that some of our `#include` get processed as `#import`, > I believe the same code gets executed for our use-case. Because our setup is > so unusual, producing a repro is

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-11 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Are your `textual` headers meant to be included more than once? If not, do they use header guards or `#pragma once`? https://github.com/llvm/llvm-project/pull/83660 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-10 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > @ian-twilightcoder this change seemed to cause our internal builds to run out > of source location space. > > ``` > remark: source manager location address space usage: [-Rsloc-usage] > note: 408559B in local locations, 2146921126B in locations loaded from AST >

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-05 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/83660 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-04-04 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/83660 >From 63ff00ec49ac20c5ac97bd673166dabb0fb56136 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Fri, 1 Mar 2024 22:17:09 -0800 Subject: [PATCH] [clang][modules] Headers meant to be included multiple

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-04-04 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/86748 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-04-04 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > Is that still worth mention in the release notes do you think? > > Oh duh, that's right, this requires someone to define the `__need` macro to > get it, so no, I don't think it needs a release note. Sorry for the noise!  thanks for bearing with me on this!

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-04-04 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > LGTM, though we should have a release note about the change because we've > been exposing the macro since Clang 17. I don't think this warrant a > potentially breaking change notice, though, just a regular bugfix one. I think we weren't exposing `unreachable` in C++

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-04-02 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > > FWIW, I did verify that it's very unlikely the changes in this PR will > > > break existing code: > > > https://sourcegraph.com/search?q=context:global+__need_unreachable+-file:.*clang.*=keyword=0, > > > so that's a good thing. > > > > I do wonder if we could

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-04-01 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > FWIW, I did verify that it's very unlikely the changes in this PR will break > existing code: > https://sourcegraph.com/search?q=context:global+__need_unreachable+-file:.*clang.*=keyword=0, > so that's a good thing. > > > I do wonder if we could have the broader

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-29 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: I do wonder if we could have the broader builtin headers discussion independent of this patch? Is everyone happy with this patch? We can keep talking about the builtin headers in here independent of merging right? https://github.com/llvm/llvm-project/pull/86748

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-29 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: @ldionne @AaronBallman is there anything I need to do before merging this? https://github.com/llvm/llvm-project/pull/86748 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-28 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > I still don't understand how that works in case you do end up including a > header from the platform that (re)defines `unreachable`, for example. > > The same problem also applies today to e.g. `size_t` and anything else > provided by the Clang builtin headers. If a

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-27 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > (for example, we now include `string.h` and `stdbit.h` in freestanding, both > of which provide a lot of function interfaces) We do? I don't see those in lib/Headers https://github.com/llvm/llvm-project/pull/86748 ___

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-26 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > I'm checking with the C and C++ Compatibility study group (SG22) for what's > expected here. Prior to adding `__need_unreachable` in LLVM 18, clang would never declare `unreachable()` in C++ mode, but would defer to the C++ library to do that. I think we should

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-26 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/86748 >From e67c757c7cdd1837008e573295e87e3ebec5382d Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 26 Mar 2024 16:19:38 -0700 Subject: [PATCH] [Headers] Don't declare unreachable() from stddef.h in

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-26 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/86748 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-26 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/86748 Even if __need_unreachable is set, stddef.h should not declare unreachable() in C++ because it conflicts with the declaration in . >From bfa16401ee26425492ce52daabe4144ea70da973 Mon Sep 17 00:00:00

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-13 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/84127 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-13 Thread Ian Anderson via cfe-commits
@@ -301,10 +301,9 @@ bool Module::directlyUses(const Module *Requested) { if (Requested->isSubModuleOf(Use)) return true; - // Anyone is allowed to use our builtin stdarg.h and stddef.h and their - // accompanying modules. - if (Requested->getTopLevelModuleName()

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-13 Thread Ian Anderson via cfe-commits
@@ -301,10 +301,9 @@ bool Module::directlyUses(const Module *Requested) { if (Requested->isSubModuleOf(Use)) return true; - // Anyone is allowed to use our builtin stdarg.h and stddef.h and their - // accompanying modules. - if (Requested->getTopLevelModuleName()

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > I'm not excited by the complexity we are moving toward with the builtin > headers. But I don't have any alternatives. > > Given the situation we are in, I think the change is ok. But I'd like someone > else to look at it as it is tricky to reason about it. No

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-12 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > Sometimes it does confuse clang, at least I saw problems with a `typedef > > enum` when I made an include-once header `textual`. > > Ok, I see. I would just consider it a bug, not a design decision. > > > That's correct. `#import` is an external source - often it

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-12 Thread Ian Anderson via cfe-commits
@@ -7,6 +7,11 @@ *===---=== */ -#ifndef offsetof +/* + * When -fbuiltin-headers-in-system-modules is set this is a non-modular header + * and needs to behave as if it was textual. + */ +#if

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-11 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/84127 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-11 Thread Ian Anderson via cfe-commits
@@ -7,6 +7,11 @@ *===---=== */ -#ifndef offsetof +/* + * When -fbuiltin-headers-in-system-modules is set this is a non-modular header + * and needs to behave as if it was textual. + */ +#if

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-11 Thread Ian Anderson via cfe-commits
@@ -2498,9 +2498,12 @@ void ModuleMapParser::parseHeaderDecl(MMToken::TokenKind LeadingToken, } bool NeedsFramework = false; - // Don't add the top level headers to the builtin modules if the builtin headers - // belong to the system modules. - if

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-11 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > To clarify a little bit > > > [...] The "already included" state is global across all modules (which is > > necessary so that non-modular headers don't get compiled into multiple > > translation units and cause redeclaration errors). > > The necessity isn't

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-11 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/83660 >From 1cb3d459f3a9ae73ac98bf8c06b905d788be954f Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Fri, 1 Mar 2024 22:17:09 -0800 Subject: [PATCH] [clang][modules] Headers meant to be included multiple

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-06 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > Still need to check the code but > > > Make the __stddef_ headers be non-modular in > > -fbuiltin-headers-in-system-modules and restore them back to not respecting > > their header guards. Still define the header guards though. > > sounds quite questionable. They

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/84127 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/84127 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/84127 >From e34ccad2b82b75c050d12bbb987529c320c0df9d Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Tue, 5 Mar 2024 22:56:36 -0800 Subject: [PATCH] [clang][modules] giving the __stddef_ headers their own

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
@@ -7,7 +7,7 @@ *===---=== */ -#if !defined(NULL) || !__has_feature(modules) +#if !defined(NULL) || !__building_module(_Builtin_stddef) ian-twilightcoder wrote: ``` #if !defined(NULL) ||

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: We should consider this for LLVM 18, it's a regression from https://reviews.llvm.org/D159064 https://github.com/llvm/llvm-project/pull/84127 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (PR #84127)

2024-03-05 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/84127 On Apple platforms, some of the stddef.h types are also declared in system headers. In particular NULL has a conflicting declaration in . When that's in a different module from <__stddef_null.h>,

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-04 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > Thanks to @Bigcheese for helping with this patch. > > https://reviews.llvm.org/D26267 looks like the most recent significant update > to this code that we could find. It had an additional allowance where clang > headers that were _not_ marked `textual` could be

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-04 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/83660 >From f90fe8b1b7c73b68614ade3cf7e1c292f02d3573 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Fri, 1 Mar 2024 22:17:09 -0800 Subject: [PATCH] [clang][modules] Headers meant to be included multiple

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-04 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/83660 >From 08681ff77f432806316109146ab4fef058137648 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Fri, 1 Mar 2024 22:17:09 -0800 Subject: [PATCH] [clang][modules] Headers meant to be included multiple

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-04 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: > > Once a file has been `#import`'ed, it gets stamped as if it was `#pragma > > once` and will not be re-entered, even on #include. > > Can you explain how this is happening? The only place where > `HeaderFileInfo::isPragmaOnce` is set to `true` is in >

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-02 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: ``` error: 'expected-error' diagnostics seen but not expected: File /var/lib/buildkite-agent/builds/linux-56-59b8f5d88-6mhbj-1/llvm-project/clang-ci/clang/test/Modules/explicit-build-overlap.cpp Line 11: module use does not directly depend on a module exporting

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-01 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/83660 >From 771c0740dcc438d99baf4ad9555bc57e963001df Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Fri, 1 Mar 2024 22:17:09 -0800 Subject: [PATCH] [clang][modules] Headers meant to be included multiple

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-01 Thread Ian Anderson via cfe-commits
ian-twilightcoder wrote: Thanks to @Bigcheese for helping with this patch. https://reviews.llvm.org/D26267 looks like the most recent significant update to this code that we could find. It had an additional allowance where clang headers that were _not_ marked `textual` could be re-entered. I

[clang] [clang][modules] Headers meant to be included multiple times can be completely invisible in clang module builds (PR #83660)

2024-03-01 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/83660 Once a file has been `#import`'ed, it gets stamped as if it was `#pragma once` and will not be re-entered, even on #include. This means that any errant #import of a file designed to be included

[clang] [Docs] Add release note about Clang-defined target OS macros (PR #79879)

2024-01-29 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/79879 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Remove the builtin_headers_in_system_modules feature (PR #75262)

2023-12-13 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/75262 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Remove the builtin_headers_in_system_modules feature (PR #75262)

2023-12-12 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder created https://github.com/llvm/llvm-project/pull/75262 __has_feature(builtin_headers_in_system_modules) was added in https://reviews.llvm.org/D159483 to be used in the stdarg/stddef implementation headers. It ended up being unnecessary, but I forgot to

[clang] [Fix] Disable fdefine-target-os-macros for now (PR #74886)

2023-12-08 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/74886 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

2023-12-07 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/74676 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

2023-12-06 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/74676 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

2023-12-06 Thread Ian Anderson via cfe-commits
@@ -0,0 +1,131 @@ +// RUN: %clang -### --target=arm64-apple-darwin %s 2>&1 | FileCheck %s --check-prefix=DEFAULT-OPTION + +// RUN: %clang -dM -E --target=arm64-apple-macos %s 2>&1 \ +// RUN: | FileCheck %s -DMAC=1 \ +// RUN:-DOSX=1 \ +// RUN:

[clang] [Modules] textual headers in submodules never resolve their `use`s (PR #69651)

2023-10-20 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/69651 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] textual headers in submodules never resolve their `use`s (PR #69651)

2023-10-19 Thread Ian Anderson via cfe-commits
https://github.com/ian-twilightcoder updated https://github.com/llvm/llvm-project/pull/69651 >From 7b88bf3102240d1734feab8919a049f8a92ca0e0 Mon Sep 17 00:00:00 2001 From: Ian Anderson Date: Thu, 19 Oct 2023 15:22:11 -0700 Subject: [PATCH] [Modules] textual headers in submodules never resolve

  1   2   >