Comments (12)
We should probably assume that implementations will support the full C99 feature as an extension, which means we need a designator for [3].
from cxx-abi.
How are those distinct? I'm probably missing something, but to me those two look like two instantiations of function f, which are only possible if the template parameter T has either a member "a" then "b", or "c" then "d", which all can be initialised from integers. If you passed a type T that has a, b, c, d or c, d, a, b, then it would be an ambiguous overload.
Going to read the paper now to see if I can answer my own question.
from cxx-abi.
They are distinct due to [temp.over.link]p4-6: corresponding parameter types contain expressions that name template parameters, and those expressions are neither equivalent nor functionally equivalent.
I believe you may be correct that it is not possible to unambiguously use them both in a single translation unit for an arbitrary set of template arguments. Unfortunately, that does not matter for the ODR; if it did, I think there would be a lot of stuff we wouldn't have to mangle.
from cxx-abi.
Thanks for the reference. I was going to say that we don't need the values that were used to initialise since they aren't used in the actual call, but then I realised that you could have:
template<typename T> void f(decltype(T{.a = 1, .b = nullptr}));
If the conversion from nullptr to b's type fails, then this is not a suitable overload. That means we do need the values used.
Anyway, as you said, we may expect compilers to support C99 extensions, like nested initialisation. So if we had:
template<typename T> void f(decltype(T{.a.b = 1, .b = 2}));
Would that mangle instead as il di 1a1b Li1E di 1b Li1E E
?
I assume an array declaration [1] = 2
would then be il di 1_ Li2E E
, as array subscripts are always size_t
and thus need no type specifier.
Finally, extracted from the kernel:
[0 ... __NR_syscall_max] = &sys_ni_syscall,
becomes il di 0_547_ Xad12sys_ni_syscallE E
(current value of __NR_syscall_max is 548 on x86-64). Or maybe il di 0_547_ L12sys_ni_syscallE E
if we use the expansion since this is not a dependent name.
from cxx-abi.
Would that mangle instead as
il di 1a1b Li1E di 1b Li1E E
?
My suggestion was that it would mangle as il di 1a di 1b Li1E di 1b Li1E E
. Under your proposal we would need a terminator for the list of designators, which seems like the wrong tradeoff given that a single-level designator is likely to be vastly more common.
I assume an array declaration
[1] = 2
would then beil di 1_ Li2E E
That would mean { ._ = 2 }
. Also, we need an expression here not just an index, since {[sizeof(T)] = 1}
is valid. di
<expr> doesn't quite work, because {[a] = 1}
and {.a = 1}
would mangle the same, but we could pick a different prefix, such as dx
<expr> (d
esignator index
).
[0 ... __NR_syscall_max] =
Sure, if we want to support GNU extensions as well as C99 extensions, maybe dX
<expr> <expr> would work as a mangling for this.
from cxx-abi.
My suggestion was that it would mangle as
il di 1a di 1b Li1E di 1b Li1E E
. Under your proposal we would need a terminator for the list of designators, which seems like the wrong tradeoff given that a single-level designator is likely to be vastly more common.
I imagined that it would terminate at the first L or X, but sure, repeating di
is a good idea too.
For the array, I'd recommend ix <expression>
(for "index", same as the mangling for operator[]
). That would make
[obj[1]] = 2
mangle as ix Xix3objLi1EE Li2E
(or ix XixL_Z3objELi1EE Li2E
, depending on what that obj is).
In fact, for the dot, maybe dt <unresolved-name>
instead of di
?
::= dt <expression> <unresolved-name> # expr.name
Sure, if we want to support GNU extensions as well as C99 extensions, maybe
dX <expr> <expr>
would work as a mangling for this.
Just being careful if some vendor wants to do this. But I'd recommend iX <expr> <expr>
instead
from cxx-abi.
I imagined that it would terminate at the first
L
orX
, but sure, repeatingdi
is a good idea too.
This is an arbitrary expression context, not something like a <template-arg> with a very restrictive grammar. So we can't use that rule, and can't use dt
or ix
either.
from cxx-abi.
Ah, right, I see il
is already there:
::= il <expression> E # {expr-list}, braced-init-list in any other context
I hadn't noticed it before, I thought it was new and then allowed for a new grammar expansion.
(shouldn't there be a + after <expression>
?)
from cxx-abi.
Fixed (to be an <expression>*).
from cxx-abi.
While you're at it...
If the braced-init-list is parenthesized, this is not a direct-list-initialization, and it should be mangled with
cv
and a nestedil
; for example,MyArray({1,2,3})
should be mangledcv7MyArrayliLi1ELi2ELi3EE
.
The il
is transposed as li
.
from cxx-abi.
Also fixed, thanks!
from cxx-abi.
PR has been merged.
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.