From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by sourceware.org (Postfix) with ESMTPS id 511CE3858C54 for ; Mon, 27 Mar 2023 22:48:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 511CE3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.washington.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.washington.edu Received: by mail-vs1-xe33.google.com with SMTP id cu36so8878969vsb.7 for ; Mon, 27 Mar 2023 15:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1679957294; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kw0Nj6vWKt/85OXpkF+mEkbXSxtc6ckCWjLDxj1TRw8=; b=PH1RU4HbxThimBK0e3VUO3gxW8Qlsxg2XM85m0M5pkjfpQnn4JEIquIGv90WBanZmK GwkXHzmaleLKW0BIcqygAz/fqPDFYV/SsjANPelZ6X1XhaffmC5DHlMRlkgvFz8QjBib gNtbYOArj0jTBWyVwGgVWLT+ga0n4zOGLQcXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679957294; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kw0Nj6vWKt/85OXpkF+mEkbXSxtc6ckCWjLDxj1TRw8=; b=bRuMoeD+vZJa7tV0eISuqwn1EO40SC4u2+/uFX4ZU6zwtnYpzj5Kat4lmXlvmaBi/w JPEBc+mPhuGYGWwdTb6pXYt4dz4JhBaiqWBtoesWc0Lw7fPmnGjDmrodtFba1AJp41Hu 8qOn2tfgektiBaFvluRto9O5ZL135fjO1L7gX+gl1cL5bP9+ekUPe7kdA8DsfbADJDEk iq43J38qdAP5HKiEN9DB/59rrY9yvBPaXsEH9vcBROMkO9DD7u3RSOX229Wp/nSnH1CT XR/meyagzjZPa1cf4jQ5Ar00v2uA5lot45VuUpV2+Ef4JfuZda2w4Vm2NZwt9M5Dme07 XYaw== X-Gm-Message-State: AAQBX9e3Ctaq89uswBbhKdsQEX4oPnH0QJMLy7wWJvc0k/WB0gquHnKY Aw8DwyNBqJGKr0ie7yxHkdclreeyoTjtHULOCPE+3g== X-Google-Smtp-Source: AKy350ai5RQjSTOp9V4GyNz2ruxjzKCVmcNQGEsPg7nPDabWYdFwsgSCCuHnN7Ri0Tldg+RSvpHEEDTqdmRj6b84JLE= X-Received: by 2002:a67:d99b:0:b0:402:9b84:1be4 with SMTP id u27-20020a67d99b000000b004029b841be4mr7005259vsj.6.1679957294648; Mon, 27 Mar 2023 15:48:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ken Matsui Date: Mon, 27 Mar 2023 15:48:03 -0700 Message-ID: Subject: Re: [GSoC] Conflicted Built-in Trait Name To: Roy Jacobson Cc: Jonathan Wakely , gcc@gcc.gnu.org, "libstdc++" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jacobson's email was treated as spam somehow. Sorry for missing your email. On Mon, Mar 27, 2023 at 2:59=E2=80=AFPM Jonathan Wakely wrote: > > On Sat, 25 Mar 2023 at 12:23, Roy Jacobson via Libstdc++ > wrote: > > > > Clang has been providing __is_void for a very long time now, and is > > definitely compatible with libstdc++. Does defining this builtin cause = a > > problem? Might be that the lookup rules for builtins are different or > > something. > > > > https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitiv= es > > Clang has special hacks that allow it to handle libstdc++ headers. > When it sees the use of a built-in trait like __is_void used as an > identifier, it disables the built-in and treats it as a normal > identifier for the rest of the translation unit. GCC doesn't do that, > so "it compiles with Clang" isn't really relevant here. > > > > > > On Sat, 25 Mar 2023 at 15:08, Ken Matsui via Gcc wrot= e: > > > > > Hi, > > > > > > I am working on the GSoC project, "C++: Implement compiler built-in > > > traits for the standard library traits". > > > > > > Built-in trait naming simply adds two underscores (__) to the origina= l > > > trait name. However, the same names are already in use for some > > > built-in traits, such as is_void, is_pointer, and is_signed. > > > > > > For example, __is_void is used in the following files: > > > > > > * gcc/testsuite/g++.dg/tm/pr46567.C > > > * libstdc++-v3/include/bits/cpp_type_traits.h > > > > > > In this case, are we supposed to change the existing same name in the > > > code to something like ____is_void (four underscores)? Or is it bette= r > > > to break the naming convention of built-in traits like > > > __is_void_builtin? > > > > > > Sincerely, > > > Ken Matsui > > > > > >