AaronBallman 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 t
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
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!
https:
AaronBallman 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!
https://github.com/llvm/llvm-project/pull/86748
__
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++
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.*&patternType=keyword&sm=0,
> > > so that's a good thing.
> > > > I do wonder
AaronBallman 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.*&patternType=keyword&sm=0,
> > so that's a good thing.
> > > I do wonder if we could hav
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.*&patternType=keyword&sm=0,
> so that's a good thing.
>
> > I do wonder if we could have
AaronBallman 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.*&patternType=keyword&sm=0,
so that's a good thing.
> I do wonder if we could have the broader built
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
___
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/
michaelrj-google wrote:
I'm fine with changing our definition to better coordinate with libc++, though
we should probably discuss that on someplace other than this patch.
https://github.com/llvm/llvm-project/pull/86748
___
cfe-commits mailing list
cfe
philnik777 wrote:
> Re: there being observable differences between a header in C vs C++ mode,
> that's already a thing.
>
> The definition for `isinf` in math.h is specified to be a macro in C, but
> specified to be a function in C++. We're already doing `#ifdef __cplusplus`
> for that (see
michaelrj-google wrote:
Re: there being observable differences between a header in C vs C++ mode,
that's already a thing.
The definition for `isinf` in math.h is specified to be a macro in C, but
specified to be a function in C++. We're already doing `#ifdef __cplusplus` for
that (see
https:
nickdesaulniers wrote:
> I think I am generally deeply confused about what should be provided by the
> compiler and what should be provided by the C Standard Library on any given
> platform.
+1
> Doing otherwise and trying to be "helpful" in Clang only creates confusion
> and forces C librar
lntue wrote:
FYI @nickdesaulniers @michaelrj-google
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
AaronBallman wrote:
> I mean that `stddef.h` would be modified to provide it as a function instead
> of a macro. In C++ it would simply never be a macro.
Yeah, that could be done too, but it seems pretty unclean IMO (at least when
aiming for an ideal implementation) -- C++ changing the content
philnik777 wrote:
I mean that `stddef.h` would be modified to provide it as a function instead of
a macro. In C++ it would simply never be a macro.
https://github.com/llvm/llvm-project/pull/86748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> > I can see WG21 solving this either by removing `unreachable` from `cstddef`
> > or by requiring `utility` to guard against the macro via implementation
> > magic (personally, I think `utility` should guard against it because of
> > users including `stddef.h` directly) a
philnik777 wrote:
> I can see WG21 solving this either by removing `unreachable` from `cstddef`
> or by requiring `utility` to guard against the macro via implementation magic
> (personally, I think `utility` should guard against it because of users
> including `stddef.h` directly) and it woul
AaronBallman wrote:
> > `unreachable` is morally similar to `offsetof` in that it's a macro
> > interface where the implementation can give better results by expanding to
> > a builtin than a library is likely to be able to give via a naive
> > implementation, but the interfaces _can_ be provi
philnik777 wrote:
> `unreachable` is morally similar to `offsetof` in that it's a macro interface
> where the implementation can give better results by expanding to a builtin
> than a library is likely to be able to give via a naive implementation, but
> the interfaces _can_ be provided by a C
ldionne wrote:
> > Thanks for the explanation, @AaronBallman . I think I am generally deeply
> > confused about what should be provided by the compiler and what should be
> > provided by the C Standard Library on any given platform. From your reply,
> > it looks like there's no clear rule and
AaronBallman wrote:
> Thanks for the explanation, @AaronBallman . I think I am generally deeply
> confused about what should be provided by the compiler and what should be
> provided by the C Standard Library on any given platform. From your reply, it
> looks like there's no clear rule and Cla
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
ldionne wrote:
Thanks for the explanation, @AaronBallman . I think I am generally deeply
confused about what should be provided by the compiler and what should be
provided by the C Standard Library on any given platform. From your reply, it
looks like there's no clear rule and Clang basically
AaronBallman 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
Sorry for the confusion! "We" being WG14 (the C committee). We (Clang) haven't
done anything abou
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
___
cfe-c
AaronBallman wrote:
> > > Why do the Clang builtin headers even try to define this? Shouldn't this
> > > be provided by the platform's C library instead? I am really confused
> > > about what's the intended layering here and it seems to me like Clang is
> > > overstepping its responsibilities
ldionne wrote:
> > Why do the Clang builtin headers even try to define this? Shouldn't this be
> > provided by the platform's C library instead? I am really confused about
> > what's the intended layering here and it seems to me like Clang is
> > overstepping its responsibilities by basically
https://github.com/AaronBallman requested changes to this pull request.
Marking as requesting changes so this isn't accidentally landed when there's an
open question as to why it's needed in the first place.
https://github.com/llvm/llvm-project/pull/86748
___
AaronBallman wrote:
> Why do the Clang builtin headers even try to define this? Shouldn't this be
> provided by the platform's C library instead? I am really confused about
> what's the intended layering here and it seems to me like Clang is
> overstepping its responsibilities by basically imp
ldionne wrote:
Why do the Clang builtin headers even try to define this? Shouldn't this be
provided by the platform's C library instead? I am really confused about what's
the intended layering here and it seems to me like Clang is overstepping its
responsibilities by basically implementing par
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 keep
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 C
Bigcheese wrote:
I'm checking with the C and C++ Compatibility study group (SG22) for what's
expected here.
https://github.com/llvm/llvm-project/pull/86748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
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
llvmbot wrote:
@llvm/pr-subscribers-backend-x86
@llvm/pr-subscribers-clang
Author: Ian Anderson (ian-twilightcoder)
Changes
Even if __need_unreachable is set, stddef.h should not declare unreachable() in
C++ because it conflicts with the declaration in .
---
Full diff: https://g
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 200
39 matches
Mail list logo
