Version 1.3 of ais/conflict.txt

Unformatted version of ais/conflict.txt version 1.3
Other versions for file ais/conflict.txt

!comment This file contains Corrigendum conflicts for Corrigendum 1.
!comment Conflicts occur when multiple defect reports change the same
!comment paragraph of the standard.
!comment This file (and the reading of it in the program) would need to
!comment be changed for a new Corrigendum.
!comment The paragraphs must be in sorted order!!
!corrigendum 7.06.01 (13)
!AI-00182
!AI-00169
@drepl The anonymous objects created by function calls and by @fa<aggregate>s are finalized no later than the end of the innermost enclosing @fa<declarative_item> or @fa<statement>; if that is a @fa<compound_statement>, they are finalized before starting the execution of any statement within the @fa<compound_statement>. @dby If the @fa<object_name> in an @fa<object_renaming_declaration>, or the actual parameter for a generic formal @b<in out> parameter in a @fa<generic_instantiation>, denotes an anonymous object created by a function call, or a subcomponent of it, the anonymous object is not finalized until after it is no longer accessible via any name. Otherwise, the anonymous objects created by function calls and by @fa<aggregate>s are finalized no later than the end of the innermost enclosing @fa<declarative_item> or @fa<statement>; if that is a @fa<compound_statement>, they are finalized before starting the execution of any statement within the @fa<compound_statement>. If a transfer of control or raising of an exception occurs prior to performing a finalization of an anonymous object, the anonymous object is finalized as part of the finalizations due to be performed for the object's innermost enclosing master.
!corrigendum 8.03 (26)
!AI-00044
!AI-00150
@drepl An explicit declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the explicit declaration. Similarly, the @fa<context_clause> for a @fa<subunit> is illegal if it mentions (in a @fa<with_clause>) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. @dby A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the @fa<context_clause> for a @fa<subunit> is illegal if it mentions (in a @fa<with_clause>) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant.
!corrigendum 8.05.04 (5)
!AI-00135
!AI-00145
@drepl The profile of a renaming-as-body shall be subtype-conformant with that of the renamed callable entity, and shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the subprogram it declares takes its convention from the renamed subprogram; otherwise the convention of the renamed subprogram shall not be Intrinsic. @dby The profile of a renaming-as-body shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the profile shall be mode-conformant with that of the renamed callable entity and the subprogram it declares takes its convention from the renamed subprogram; otherwise the profile shall be subtype-conformant with that of the renamed callable entity and the convention of the renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal if the declaration occurs before the subprogram is frozen, and the renaming renames the subprogram itself, either directly or indirectly.
!corrigendum 8.05.04 (8)
!AI-00064
!AI-00135
@drepl For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. @dby For a call to a subprogram whose body is given as a renaming-as-body, the execution of the renaming-as-body is equivalent to the execution of a @fa<subprogram_body> that simply calls the renamed subprogram with its formal parameters as the actual parameters and, if a function, returns the value of the call.
For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called.
@i<@s8<Bounded (Run-Time) Errors>>@hr If a subprogram directly or indirectly renames itself, then it is a bounded error to call that subprogram. Possible consequences are that Program_Error or Storage_Error is raised, or that the call results in an indefinite loop.
!corrigendum 10.01.05 (7)
!AI-00041
!AI-00199
@dinsa Certain program unit pragmas are defined to be @i<library unit pragmas>. The name, if any, in a library unit pragma shall denote the declaration of a library unit. @dinst @i<@s8<Static Semantics>>
A library unit pragma that applies to a generic unit does not apply to its instances. Any other program unit pragma that applies to a generic unit applies to an instance of the generic unless the instance has an overriding pragma.
!corrigendum 13.01(11)
!AI-00117
!AI-00137
@drepl Representation aspects of a generic formal parameter are the same as those of the actual. A type-related representation item is not allowed for a descendant of a generic formal untagged type. @dby Representation aspects of a generic formal parameter are the same as those of the actual. Representation aspects of a partial view are the same as those of the full view. A type-related representation item, other than the stream-oriented attributes Read, Write, Input, and Output, is not allowed for a descendant of a generic formal untagged type.
!corrigendum 13.12(9)
!AI-00130
!AI-00190
@dinsa An implementation may place limitations on the values of the @fa<expression> that are supported, and limitations on the supported combinations of restrictions. The consequences of violating such limitations are implementation defined. @dinss Implementations are permitted to omit restriction checks for code that is recognized at compile time to be unreachable and for which no code is generated.
Whenever enforcement of a restriction is not required prior to execution, an implementation may nevertheless enforce the restriction prior to execution of a partition to which the restriction applies, provided that every execution of the partition would violate the restriction.
!corrigendum A.12.01 (29)
!AI-00026
!AI-00001
@drepl The Stream function returns a Stream_Access result from a File_Type object, thus allowing the stream-oriented attributes Read, Write, Input, and Output to be used on the same file for multiple types. @dby The Stream function returns a Stream_Access result from a File_Type object, thus allowing the stream-oriented attributes Read, Write, Input, and Output to be used on the same file for multiple types. Stream propagates Status_Error if File is not open. If positioning is supported for the File_Type object, then the default implementations of these attributes add one to the current index.
!corrigendum E.02.02 (9)
!AI-00004
!AI-00164
@drepl An access type declared in the visible part of a remote types or remote call interface library unit is called a @i<remote access type>. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type. @dby An access type declared in the visible part of a remote types or remote call interface library unit is called a @i<remote access type>. Such a type shall be either an access-to-subprogram type, a general access type that designates a class-wide limited private type, or a class-wide private type extension whose ancestors are private type extensions and a limited private type. A type that is derived from a remote access type is also a remote access type.
Questions? Ask the ACAA Technical Agent