Commit 6df65f93 authored by urbant's avatar urbant
Browse files

Several "on-hold" tests resolved and moved to the ATS

parent 7a7ae47d

misc/ATS-on_hold/15_templates/1506_referencing_elements_of_templates_or_template_fields/150602_referencing_record_and_set_fields/Sem_150602_ReferencingRecordAndSetFields_003.ttcn

deleted100644 → 0
+0 −55
Original line number Diff line number Diff line 
/*****************************************************************

 ** @author   STF 433

 ** @version  0.0.1

 ** @purpose  1:15.6.2, ? shall be returned for mandatory subfields and * shall be returned for optional subfields.

 ** @verdict  pass accept, ttcn3verdict:pass

 *****************************************************************/

//on hold till resolution of CR6711



module Sem_150602_ReferencingRecordAndSetFields_003 {



    type component GeneralComp { }



    type record MyRecordTwo {

        integer g1,

        MyRecordTwo g2 optional

    }



    type record MyRecordOne {

        integer f1 optional,

        MyRecordTwo f2 optional

    }



    testcase TC_Sem_150602_ReferencingRecordAndSetFields_003() runs on GeneralComp {

        var boolean v_matchRes;

        var template MyRecordOne m_R1 := {

            f1 := 0,

            f2 := ?

        }



        // m_R2.g1 is mandatory, therefore it shall be ?

        // m_R2.g2 is optional, therefore it shall be *

        var template MyRecordTwo m_R2 := m_R1.f2;

        var template(value) MyRecordTwo m_value := {

            g1 := 5,

            g2 := omit

        }



        // match against {?, *}

        v_matchRes := match(m_value, MyRecordTwo:{m_R2.g1, m_R2.g2});





        if (v_matchRes) {

            setverdict(pass);

        } else {

            setverdict(fail, "match against {?, *}");

        }



    }



    control{

        execute(TC_Sem_150602_ReferencingRecordAndSetFields_003());

    }





}
 
 No newline at end of file

misc/ATS-on_hold/15_templates/1506_referencing_elements_of_templates_or_template_fields/150602_referencing_record_and_set_fields/Sem_150602_ReferencingRecordAndSetFields_004.ttcn

deleted100644 → 0
+0 −54
Original line number Diff line number Diff line 
/*****************************************************************

 ** @author   STF 433

 ** @version  0.0.1

 ** @purpose  1:15.6.2, ? shall be returned for mandatory subfields and * shall be returned for optional subfields.

 ** @verdict  pass accept, ttcn3verdict:pass

 *****************************************************************/

//on hold till resolution of CR6711



module Sem_150602_ReferencingRecordAndSetFields_004 {



    type component GeneralComp { }



    type record MyRecordTwo {

        integer g1,

        MyRecordTwo g2 optional

    }



    type record MyRecordOne {

        integer f1 optional,

        MyRecordTwo f2 optional

    }



    testcase TC_Sem_150602_ReferencingRecordAndSetFields_004() runs on GeneralComp {

        var template MyRecordOne m_R1 := {

            f1 := 0,

            f2 := ?

        }



        // m_R2.g1 is mandatory, therefore it shall be ?

        // m_R2.g2 is optional, therefore it shall be *

        var template MyRecordTwo m_R2 := m_R1.f2;

 

        var template(value) MyRecordTwo m_value := {

            g1 := 5,

            g2 := omit

        }



        // match against {?, *} - use dotted notation to cover other expansion thread

        var boolean v_matchRes := match(m_value, MyRecordTwo:{m_R1.f2.g1, m_R1.f2.g2});





        if (v_matchRes) {

            setverdict(pass);

        } else {

            setverdict(fail, "match against {?, *} - use dotted notation to cover other expansion thread");

        }

    }



    control{

        execute(TC_Sem_150602_ReferencingRecordAndSetFields_004());

    }





}
 
 No newline at end of file

misc/ATS-on_hold/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_031.ttcn

+5 −15
Original line number Diff line number Diff line 
/*****************************************************************

 ** @author   STF 470

 ** @version  0.0.1

 ** @author   STF 470 (updated by STF 521)

 ** @version  0.0.2

 ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(present) is handled correctly.

 ** @verdict  pass accept, ttcn3verdict:pass

 *****************************************************************/



// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer

// Older versions of the core languate standard didn't allow this type of 

// modification because of restriction 15.8.c.



/*

Pro opinion:

Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.

Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.



Contra opinion

The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.



*/

// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check. 

// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to 

// stricter approach in which case the test should be change to a negative one.



module Sem_1508_TemplateRestrictions_031 {

misc/ATS-on_hold/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_032.ttcn

+5 −15
Original line number Diff line number Diff line 
/*****************************************************************

 ** @author   STF 470

 ** @version  0.0.1

 ** @author   STF 470 (updated by STF 521)

 ** @version  0.0.2

 ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(omit) is handled correctly.

 ** @verdict  pass accept, ttcn3verdict:pass

 *****************************************************************/



// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer

// Older versions of the core languate standard didn't allow this type of 

// modification because of restriction 15.8.c.



/*

Pro opinion:

Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.

Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.



Contra opinion

The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.



*/

// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check. 

// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to 

// stricter approach in which case the test should be change to a negative one.



module Sem_1508_TemplateRestrictions_032 {

misc/ATS-on_hold/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_033.ttcn

+5 −15
Original line number Diff line number Diff line 
/*****************************************************************

 ** @author   STF 470

 ** @version  0.0.1

 ** @author   STF 470 (updated by STF 521)

 ** @version  0.0.2

 ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template is handled correctly.

 ** @verdict  pass accept, ttcn3verdict:pass

 *****************************************************************/



// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer

// Older versions of the core languate standard didn't allow this type of 

// modification because of restriction 15.8.c.



/*

Pro opinion:

Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.

Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.



Contra opinion

The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.



*/

// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check. 

// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to 

// stricter approach in which case the test should be change to a negative one.



module Sem_1508_TemplateRestrictions_033 {