Comments (6)
from cxx-abi.
Added a pull request describing the rule I think we've agreed on. This matches EDG's behavior, mostly matches Clang's and is substantially different from GCC's :)
In particular, Clang only renumbers closure types in template instantiations, and inherits the numbering for everything else. I believe that is a valid approach in language as it stands today, but only because there happens to be no way to pack-expand any numbered entity other than a closure type yet. I expect that to change, so adopting EDG's rule (effectively: renumber everything during template instantiation, as if we instantiated by token replay) seems best.
from cxx-abi.
Is the different treatment of constexpr if
in templates and non-templates justifiable?
from cxx-abi.
I'm also uncertain about consistently using the last token in the entity. That rule seems to be justifiable for lambdas, but I'm not sure it's reasonable for e.g. static locals. While static locals cannot be lexically nested in the same semantic context in standard C++, they can be lexically nested in vendor-extended C++ due to statement-expressions, and I think we might expect a naive compiler to pick a discriminator as soon as the declarator was processed rather than after processing the initializer.
from cxx-abi.
Is the different treatment of
constexpr if
in templates and non-templates justifiable?
Yes, I think so; constexpr if
does different things in templates and non-templates.
In a non-template, it's normal code that's just not emitted (we also turn off return type deduction, but not much else). In particular, you can instantiate a template in the not-chosen branch, using a local type from the not-chosen branch, and end up needing to emit a symbol (eg, the initializer for a templated variable). So we must number things in the non-template case.
In a template, constexpr if
fully discards the not-chosen branch: we don't even substitute into it, so there's nothing we could number even if we wanted to.
I'm also uncertain about consistently using the last token in the entity.
I think using the token at which the identity of the entity is known (the last token in the declaration, excluding a definition / body / initializer) would be reasonable. For a lambda, that'd mean you pick the {
, not the }
as in the current pull request, but I think those options are equivalent anyway, as everything inside the braces can use the lambda itself as its numbering context..
from cxx-abi.
So we must number things in the non-template case.
Hmm. This design is quite surprising to me; I understand why it's desirable for discarded sub-statements to still be well-formed, but I'm surprised they're not at least considered to be some form of unevaluated code so that its uses are never ODR-uses and we're not even tempted to actually instantiate templates, much less emit any code for them. Seems like an unforced error.
For a lambda, that'd mean you pick the
{
, not the}
as in the current pull request, but I think those options are equivalent anyway, as everything inside the braces can use the lambda itself as its numbering context.
I considered that and came to the same conclusion, but you're right that it would be more consistent to use the earlier token just to underline the point. The only reason not to would be if something about the body ever fed into the signature, but since we control this particular definition of "signature", it's easy enough to simply commit to not doing that.
from cxx-abi.
Related Issues (20)
- "Deducing this" mangling HOT 14
- Should std::rethrow_exception be covered by the EH ABI? HOT 2
- Emergency EH buffer is overspecified HOT 6
- Where is the most recent ABI document? HOT 1
- Add `[[trivial_abi]]` attribute
- Lambda POD for the purposes of layout? HOT 2
- Mangling the name of an externally visible lambda in a static data member of a class HOT 1
- Proposal: Include an optional specification for mangling names that reference anonymous symbols HOT 4
- Is it possible to form a pointer-to-data-member with offset -1 using explicit derived-to-base conversions without UB? HOT 3
- unnecessary `E`s after <expression> and mangling collisions between <expression> and <number> HOT 1
- need mangling for lambdas appearing in unevaluated operands within a class body HOT 3
- What does "forbidding the use of function templates" mean? HOT 2
- [C++20] [Modules] Do we need the concept of `key function` for class defined in module purview? HOT 25
- Missing HTML encoding in 2.3.1 Data Member Pointers HOT 2
- Proposal: document or somehow notice __cxa_init_primary_exception HOT 3
- Mangling for C++ pack indexing HOT 1
- Function and function pointer types with vendor calling conventions HOT 2
- Ambiguity in mangling grammar around type qualifiers HOT 8
- Question about section 2.9.4 HOT 4
- Questions About Non-POD Types Data Layout HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cxx-abi.