|Anonymous | Login | Signup for a new account||2019-04-25 16:33 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000062||Z.C++||[All Projects] Backend/Core||public||2011-04-15 03:21||2011-09-29 19:31|
|Target Version||0.0.9||Fixed in Version||0.0.9|
|Summary||0000062: extension __zcc_linkage|
|Description||To make the following testable, we need a compile-time extension: __zcc_linkage|
* -1: not declared in this scope
* 0: no linkage
* 1: internal linkage
* 2: external linkage, own-language
* 3: external linkage, C
The above is a compile-time constant suitable for static assertions.
C linkage: external, internal, no [C1X 6.2.2p2]
* static |-> internal [C1X 6.2.2p3]
* extern [C1X 6.2.2p4]
** no prior definition |-> external linkage
** prior definition: remap no to external; copy internal, external
*** should we warn on copying internal? [does this happen in real code?]
* declaration of a function with no specifier: pretend it's declared with extern [C1X 6.2.2p5]
* declaration of an object at file scope, no specifier: external linkage [C1X 6.2.2p5]
* no linkage [C1X 6.2.2p6]
** identifier that isn't an object or function
** identifier that is a function parameter
** block-scope identifier for an object not declared extern
** same identifier used with both internal and external linkage: undefined behavior (Z.C++ should error out) [C1X 6.2.2p7]
C++0X linkage: external, internal, no [C++0X 3.5p2 [basic.link]]
* namespace scope: name has internal linkage when [C++0X 3.5p3]
** variable, function, or function template that is explicitly static
** variable that is const or constexpr, and neither explicitly extern nor priorly declared to have external linkage
** data member of an anonymous union
* unnamed namespaces, and all namespaces declared within them at any depth, have internal linkage.
* other namespaces have external linkage
* a name with namespace scope, that has not already been given linkage, gets the linkage of the enclosing namespace if it
is the name of
** a variable
** a function
** a named class (cf. p9)
** an unnamed class defined in a typedef in which the class has the typedef name for linkage purposes (cf. 7.1.3p9)
** a named enumeration (cf. 7.2)
** an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (cf. 7.1.3)
** an enumerator belonging to an enumeration with linkage
** a template
* a member function, static data member, named class or enumeration of class scope, or an unnamed class or enumeration defined in a class-scope
typedef declaration such that the class or enumeration has the typedef name for linkage purposes, has external linkage if
the name of the class has external linkage.
* name of a function declared in block scope, and name of a variable declared by a block scope extern declaration, have linkage.
** If there is a visible prior declaration with linkage having same name and type, ignoring entities declared outside of
the innermost enclosing namespace scope, the block scope declaration declares the same entity and receives the previous linkage.
If there is more than one such declaration, the program is ill-formed.
* a block scope declaration of an entity with linkage is not found to refer to some other declaration,
then that entity is a member of the innermost enclosing namespace. But it does not introduce the member name
in its namespace scope.
* names not covered by the above have no linkage
* except as above, a name declared at block scope has no linkage
* a type is said to have linkage iff
** it is a class or enumeration type that is named, or has a name for linkage purposes, and the name has linkage
** unnamed class or enumeration member of a class with linkage
** specialization of a class template [this should be forced to have external linkage; 14.3.1 and 14.3.2 handle template argument linkage]
** fundamental type
** compound type other than a class or enumeration, compounded exclusively from types that have linkage
** cv-qualified version of a type with linkage
* type without linkage shall not be used as the type of a variable or function with external linkage unless
** entity has C language linkage (7.5)
** entity is declared within an unnamed namespace
** entity is not ODR-used (3.2), or is defined in the same translation unit. [classes that have linkage, may contain members with no linkage]
* Two names that are the same (p3), and that are declared in different scopes shall denote the same variable, function, enumerator, template, or namespace if
** both names have external linkage, or both names have internal linkage and are declared in the same translation unit, and
** both names refer to members of the same namespace, or to members, not by inheritance, of the same class, and
** when both names denote functions, the parameter-type-lists of the functions (8.3.5) are identifical, and
** when both names denote function templates, the signatures (188.8.131.52) are the same.
* After all adjustments of types (in which typedefs are replaced by their definitions), the types specified by all declarations referring to a
a given variable or function shall be identical, except that declarations for an array object can differ by the presence or absence of a major array bound (8.3.4).
Violating this doesn't require a diagnostic.
use linkage-specifications (extern "C", etc.; cf. 7.5) to link to non-C++ declarations.
|Tags||No tags attached.|
Placeholder: use -2 for "unimplemented"
Note that *.zo format needs to store type information for objects, so it has to know about type definitions even with C's no-linkage.
|2011-04-15 03:21||zaimoni||New Issue|
|2011-04-28 21:47||zaimoni||Assigned To||=> zaimoni|
|2011-04-28 21:47||zaimoni||Status||new => assigned|
|2011-05-22 20:07||zaimoni||Note Added: 0000023|
|2011-09-29 19:31||zaimoni||Status||assigned => resolved|
|2011-09-29 19:31||zaimoni||Fixed in Version||=> 0.0.9|
|2011-09-29 19:31||zaimoni||Resolution||open => fixed|
|Copyright © 2000 - 2010 MantisBT Group|