titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2024-03-27T14:41:45Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/718PER: remove trailing 0 bits from bitstrings2024-03-27T14:41:45ZBotond BaranyiPER: remove trailing 0 bits from bitstringsAccording to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is alw...According to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is always encoded as an empty bit
string).
Where there is a PER-visible constraint and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies (i.e., the bitstring
type is defined with a "NamedBitList"), the value shall be encoded with trailing 0 bits added or removed as necessary to
ensure that the size of the transmitted value is the smallest size capable of carrying this value and satisfies the effective
size constraint."
The current version of the PER encoder does not remove trailing 0 bits in any situation.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/711Unchecked module's attributes should not be cached2024-01-11T17:28:27ZBotond BaranyiUnchecked module's attributes should not be cachedA module's extension attributes can be cached (i.e. stored after they are first calculated, so they don't have to be calculated every time they're requested) before the semantic analysis of these attributes changes them (i.e. deletes som...A module's extension attributes can be cached (i.e. stored after they are first calculated, so they don't have to be calculated every time they're requested) before the semantic analysis of these attributes changes them (i.e. deletes some of them).
Consider the following example:
A.ttcn:
```
module A {
import from B all;
type record of Rec RoRec
with { encode "JSON" }
}
```
B.ttcn:
```
module B {
import from A all;
type record Rec {
integer num,
charstring str
}
external function f_enc(in Rec x) return octetstring
with { extension "prototype(convert) encode(RAW)" };
}
with {
encode "RAW"
extension "version R3A"
}
```
The following steps take place, when semantic analysis reaches module B:
- the check for imported module A is intiated (before module B itself is checked),
- the check for type RoRec in module A is initiated,
- the check for type Rec in module B is initiated (because it is contained in type RoRec),
- while checking type Rec's encodings, the parent module's attributes are calculated and cached, before the module has checked them (this results in a vector of 2 attributes, one 'encode' and one 'extension'),
- the check for type RoRec and module A is finished,
- the check for module B is initiated,
- module B's attributes are checked, this results in the extension attribute being deallocated,
- external function f_enc is checked, which requests the parent module's attributes, which returns the previously cached attributes.
The result a fatal error, because the 2nd attribute in the cache has already been deallocated.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/708Sizeof function causes fatal error2023-12-05T13:59:24ZAdam KnappSizeof function causes fatal error## Summary
In certain cases, when a function returns template and the sizeof function is used on the returning template causes FATAL_ERROR in the compiler stopping the code generation completely.
## Steps and/or TTCN-3 code to reproduc...## Summary
In certain cases, when a function returns template and the sizeof function is used on the returning template causes FATAL_ERROR in the compiler stopping the code generation completely.
## Steps and/or TTCN-3 code to reproduce
The following code reproduces the issue:
```
// lengthof and sizeof (with functions returning templates)
type record Rec {
integer a optional,
boolean b
}
type record of Rec Rec_of;
function f2() return template Rec_of {
var template Rec_of x;
x[0].a := 0;
x[0].b := ?;
x[1].a := omit;
x[1].b := false;
return x;
}
function f3() return template Rec {
var template Rec t_rec := { ?, true };
return t_rec;
}
template Rec_of RoIret_global := f2();
template Rec rec_global := f3();
testcase tc_predef_sizeof_lengthof_func_rtemp() runs on CT {
template Rec_of RoIret_local := f2();
var template Rec_of RoIret_local_var := f2();
var integer size := lengthof(RoIret_global);
if (size != 2) {
setverdict(fail, "#1: ", size);
}
size := lengthof(RoIret_local);
if (size != 2) {
setverdict(fail, "#2: ", size);
}
size := lengthof(RoIret_local_var);
if (size != 2) {
setverdict(fail, "#3: ", size);
}
size := sizeof(rec_global);
if (size != 2) {
setverdict(fail, "#4: ", size);
}
size := sizeof(RoIret_global);
if (size != 2) {
setverdict(fail, "#5: ", size);
}
size := sizeof(RoIret_local);
if (size != 2) {
setverdict(fail, "#6: ", size);
}
size := sizeof(RoIret_local_var);
if (size != 2) {
setverdict(fail, "#7: ", size);
}
setverdict(pass);
}
```
## What is the current bug behavior?
FATAL_ERROR happens
## What is the expected correct behavior?
Compile without error
## Titan version
Titan 9.0.0
/cc @aknappqwtBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/707Compiler issue: compilation is blocked using 100% of the CPU2023-11-15T15:08:31ZBotond BaranyiCompiler issue: compilation is blocked using 100% of the CPUSee: https://www.eclipse.org/forums/index.php/t/1113807/
/cc @aknappqwt @mmagyariSee: https://www.eclipse.org/forums/index.php/t/1113807/
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/675module renaming does not work2024-02-19T16:35:33ZLevente Erősmodule renaming does not work## Summary
Module renaming does not work as described in Section 8.2.3.1 (EXAMPLE 4 and point i).
## Steps and/or TTCN-3 code to reproduce
In one module different from module D:
```
import from D -> DD all;
```
In module D:
```
mod...## Summary
Module renaming does not work as described in Section 8.2.3.1 (EXAMPLE 4 and point i).
## Steps and/or TTCN-3 code to reproduce
In one module different from module D:
```
import from D -> DD all;
```
In module D:
```
module D {
type integer dint;
}
```
## What is the current bug behavior?
Compilation error.
## What is the expected correct behavior?
Successful build.
## Relevant logs and/or screenshots
```
../src/modules.ttcn:11.15-16: error: at or before token `->': syntax error
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/671isvalue yields error for non-chosen field, while it should return false2023-11-20T07:33:07ZLevente Erősisvalue yields error for non-chosen field, while it should return false## Summary
According to Section 7.1.8.4, EXAMPLE 3, isvalue should yield false if its parameter is a non-chosen (sub)field of a union. Titan however, returns an error because of the referenced field not being the chosen one.
## Steps a...## Summary
According to Section 7.1.8.4, EXAMPLE 3, isvalue should yield false if its parameter is a non-chosen (sub)field of a union. Titan however, returns an error because of the referenced field not being the chosen one.
## Steps and/or TTCN-3 code to reproduce
```
type union MyUnion_isv {
integer ch1,
integer ch2
}
template MyUnion_isv mw_myUnion := { ch1 := ? }
type record MyRecord_isv {
MyUnion_isv u optional
}
template MyRecord_isv mw_myRecord := { u := mw_myUnion }
testcase isvalue_fun() runs on ct_empty{
var boolean v_checkResult := isvalue(mw_myUnion.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
v_checkResult := isvalue(mw_myRecord.u.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
v_checkResult := isvalue(m_myRecord.u.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```
../src/operators.ttcn:353.51-53: error: Reference to inactive field `ch2' in a template of union type `@operators.MyUnion_isv'. The active field is `ch1'.
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/670Rotate does not work well on partly initialized record ofs, set ofs, and arrays2023-11-20T07:32:34ZLevente ErősRotate does not work well on partly initialized record ofs, set ofs, and arrays## Summary
According to Section 7.1.7 of the TTCN-3 standard, "When the rotate operator is used for record of-s, set of-s and arrays, its left hand operand shall be at least partially initialized." However, it does not work, only with f...## Summary
According to Section 7.1.7 of the TTCN-3 standard, "When the rotate operator is used for record of-s, set of-s and arrays, its left hand operand shall be at least partially initialized." However, it does not work, only with fully initialized data elements.
## Steps and/or TTCN-3 code to reproduce
```
type record of integer ROI;
type set of integer SOI;
testcase rotatopsub() runs on ct_empty{
var integer uiarray[3], rot_uiarray[3];
uiarray[0] := 1;
uiarray[2] := 3;
var ROI uiro, rot_uiro;
uiro[0] := 1;
uiro[2] := 3;
var SOI uiso, rot_uiso;
uiso[0] := 1;
uiso[2] := 3;
rot_uiarray := uiarray @> 2;
rot_uiro := uiro @> 2;
rot_uiso := uiso @> 2;
/* if(rot_uiarray[0].isbound){setverdict(pass);}else{setverdict(fail);}
if(rot_uiro[0].isbound){setverdict(pass);}else{setverdict(fail);}
if(rot_uiso[0].isbound){setverdict(pass);}else{setverdict(fail);}
*/
}
```
## What is the current bug behavior?
Runtime error, and after uncommenting the last 3 rows, compile error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```
MTC@HUL21014: Dynamic test case error: Assignment of an unbound integer value.
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/669evaluation does not stop where it should2023-11-17T07:10:28ZLevente Erősevaluation does not stop where it should## Summary
According section 7.1.4 of the TTCN-3 standard, "Short circuit evaluation for boolean expressions is used, i.e. the evaluation of operands of logical operators is stopped once the overall result is known: in the case of the a...## Summary
According section 7.1.4 of the TTCN-3 standard, "Short circuit evaluation for boolean expressions is used, i.e. the evaluation of operands of logical operators is stopped once the overall result is known: in the case of the and operator, if the left argument evaluates to false, then the right argument is not evaluated and the whole expression evaluates to false. In the case of the or operator, if the left argument evaluates to true, then the right argument is not evaluated and the whole expression evaluates to true."
## Steps and/or TTCN-3 code to reproduce
```
testcase logicalops() runs on ct_empty{
var integer v:=0;
var integer u:=0;
if(true or (u/v==1)){setverdict(pass);}else{setverdict(fail);}
if(not(false or (u/v==1))){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Pass
## What is the expected correct behavior?
Error, as there is a division by 0 in the 2nd operand -- but this operand shall not be reached during evaluation
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/668compound type compatibility contradicts standars2023-11-22T07:18:38ZLevente Erőscompound type compatibility contradicts standars## Summary
According to section 7.1.3 of the TTCN-3 standard, "If there is a compound expression on both sides of the comparison operator, they shall both be value list notation expressions where the elements shall be of the same root t...## Summary
According to section 7.1.3 of the TTCN-3 standard, "If there is a compound expression on both sides of the comparison operator, they shall both be value list notation expressions where the elements shall be of the same root type and they shall be compared like record of values with elements of that root type." This doesn't seem to work in Titan.
## Steps and/or TTCN-3 code to reproduce
```
testcase compoundeq() runs on ct_empty{
if({1,2,3}=={1,2,3){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Error
## What is the expected correct behavior?
Pass
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:782.21: error: at or before token `)': syntax error
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/666Enumerated compatibility is too restrictive2024-01-15T16:49:30ZLevente ErősEnumerated compatibility is too restrictive## Summary
According to section 7.1.3 of the standard, same values of different enumerated types are equal if name and id are same and the two types can be converged into a consistent type (no name-id contradictions appear). Titan does ...## Summary
According to section 7.1.3 of the standard, same values of different enumerated types are equal if name and id are same and the two types can be converged into a consistent type (no name-id contradictions appear). Titan does not accept the equality check of two non-identical enumerated types though.
Note: The standard contradicts itself here: 6.2.4. contradicts the above section.
## Steps and/or TTCN-3 code to reproduce
```
type component ct_empty{}
type enumerated enum1 {egyes(1), kettes(2)};
type enumerated enum2 {kettes(2), harmas (3)};
testcase alloperators() runs on ct_empty{
var enum1 e1 := kettes;
var enum2 e2 := kettes;
if(e1==e2){setverdict(pass);}else{setverdict(fail);}
}
control{
execute(alloperators());
}
```
## What is the current bug behavior?
Error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```../src/operators.ttcn:49.10-11: error: Type mismatch: a value of type `@operators.enum1' was expected instead of `@operators.enum2'```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/648Set of compatibility is too restrictive in Titan2024-02-02T17:02:35ZLevente ErősSet of compatibility is too restrictive in Titan## Summary
Set of compatibility should not require type match of set of type, according to Section 6.3.2.3 of the TTCN standard.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b...## Summary
Set of compatibility should not require type match of set of type, according to Section 6.3.2.3 of the TTCN standard.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type set FType {
integer a optional,
integer b optional,
boolean c
}
type set GType {
integer d optional,
integer e optional,
boolean f
}
testcase set_setof_comp() runs on ct_empty{
var AType v_myVarA := { -, 1, true};
var FType v_myVarF := { a:=1, c:=true };
var GType v_myVarG := { f:=true, d:=7};
v_myVarF := v_myVarG;
//v_myVarF := v_myVarA; error
setverdict(pass);
}
```
## What is the current bug behavior?
Error. See log.
## What is the expected correct behavior?
Assignment ```v_myVarF := v_myVarG;``` is legal, as the fields are compatible.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:610.15-22: error: Type mismatch: a value of type `@datatypes.FType' was expected instead of `@datatypes.GType'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/646Enumerated compatibility is stricter in TITAN than in TTCN-3 standard2024-01-15T16:49:20ZLevente ErősEnumerated compatibility is stricter in TITAN than in TTCN-3 standard## Summary
Enumerated compatibility needs identical enumerated types to work in TITAN, while the standard (6.3.2.1) is more relaxed on this matter.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, W...## Summary
Enumerated compatibility needs identical enumerated types to work in TITAN, while the standard (6.3.2.1) is more relaxed on this matter.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, Wed, Thu, Fri, Sat, Sun
};
type enumerated EWorkDays {
Mon, Tue, Wed, Thu, Fri
};
type enumerated EComplexValues {
e_num (1),
e_expr (2+2),
e_bin_conv (bit2int('0111'B)),
e_oct_conv (oct2int('34'O)),
e_hex_conv (hex2int('AC'H))
}
type enumerated ESimpleValues {
e_num (1),
e_expr (4),
e_bin_conv (7),
e_oct_conv (52),
e_hex_conv (172)
}
testcase enum_comp() runs on ct_empty{
var EWeekDays v_myWeekDayMon := Mon
var EWorkDays v_myWorkDayMon := Mon
var EComplexValues v_myComplexValuedEnum := e_bin_conv;
var ESimpleValues v_mySimpleValuedEnum := e_bin_conv;
v_myWorkDayMon := v_myWeekDayMon
v_mySimpleValuedEnum := v_myComplexValuedEnum;
}
```
## What is the current bug behavior?
Errors
## What is the expected correct behavior?
The two last assignments shall work as the assigned value exists in the domain of the assignee and its identifier is the same too.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:509.21-34: error: Type mismatch: a value of type `@datatypes.EWorkDays' was expected instead of `@datatypes.EWeekDays'
../src/datatypes.ttcn:510.27-47: error: Type mismatch: a value of type `@datatypes.ESimpleValues' was expected instead of `@datatypes.EComplexValues'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/645universal charstring is unconditionally incompatible with charstring2024-01-15T15:18:00ZLevente Erősuniversal charstring is unconditionally incompatible with charstring## Summary
According to 6.3.1 in the standard, a universal charstring can be assigned as value to a charstring iff the former does not include special characters.
## Steps and/or TTCN-3 code to reproduce
```
testcase types_assignments...## Summary
According to 6.3.1 in the standard, a universal charstring can be assigned as value to a charstring iff the former does not include special characters.
## Steps and/or TTCN-3 code to reproduce
```
testcase types_assignments() runs on ct_empty{
v_uc := "a";
v_myCharString := v_uc;
setverdict(pass);
v_uc := "áéíőű";
@try{
v_myCharString := v_uc;
}
@catch(msg){
log(msg);
setverdict(pass);
}
}
```
## What is the current bug behavior?
This does not compile.
## What is the expected correct behavior?
Test case passes.
## Relevant logs and/or screenshots
```../src/assignments.ttcn:527.23-26: error: Type mismatch: a value of type `charstring' was expected instead of `universal charstring'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/641port type variables and constants are not allowed in Titan2024-02-29T15:52:04ZLevente Erősport type variables and constants are not allowed in Titan## Summary
According to section 6.2.9 of the TTCN-3 standard, port type parameters, variables and constants can be defined. TITAN does not allow this, however.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
ino...## Summary
According to section 6.2.9 of the TTCN-3 standard, port type parameters, variables and constants can be defined. TITAN does not allow this, however.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct2{
port mypt p;
}
type component cct{
port mypt p;
port mypt q;
}
function f_sender(mypt sp) runs on cct{
sp.send(1);
sp.receive;
setverdict(pass);
}
testcase const_port() runs on cct{
connect(self:p, self:p);
connect(self:q, self:q);
const mypt cp := p;
var mypt vp := cp;
const mypt cq := q;
var mypt vq := cq;
f_sender(p);
f_sender(q);
}
```
## What is the current bug behavior?
Compile error
## What is the expected correct behavior?
Pass after execution
## Relevant logs and/or screenshots
```
../src/control_flow.ttcn:139.15-21: error: Constant cannot be defined for port type `@control_flow.mypt2'
../src/control_flow.ttcn:140.13-20: error: Variable cannot be defined for port type `@control_flow.mypt2'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/639Reactivating defaults and second parameter of deactivate is not working2024-02-15T16:07:49ZLevente ErősReactivating defaults and second parameter of deactivate is not working## Summary
According to the TTCN-3 standard activate() can not only be used with an altstep as actual parameter, but with a default. Also, deactivate can have a second boolean parameter, which if set to true, will reactivate the current...## Summary
According to the TTCN-3 standard activate() can not only be used with an altstep as actual parameter, but with a default. Also, deactivate can have a second boolean parameter, which if set to true, will reactivate the currently deactivated default with the default's priority at deactivation. If false, the default will be activated with highest priority.
## Steps and/or TTCN-3 code to reproduce
```
module control_flow {
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct{
port mypt p;
var integer v;
}
altstep a_myDefaultBehaviour1() runs on myct{
[] p.receive{v:=1}
}
altstep a_myDefaultBehaviour2() runs on myct{
[] p.receive{v:=2}
}
altstep a_myDefaultBehaviour3() runs on myct{
[] p.receive{v:=3}
}
testcase defaults() runs on myct{
connect(self:p, self:p);
var default v_def1 := activate(a_myDefaultBehaviour1());
var default v_def2 := activate(a_myDefaultBehaviour2());
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==3){setverdict(pass);}else{setverdict(fail);}
deactivate(v_def2, true);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
activate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==2){setverdict(pass);}else{setverdict(fail);}
deactivate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
activate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
}
}
```
## What is the current bug behavior?
There is an error at ```deactivate(v_def2, true);```, as Titan does not expect the second parameter. Also, there is an error at ```activate(v_def2);``` as activate can only be called for altsteps, not defaults, according to TITAN.
## What is the expected correct behavior?
Test case should pass.
## Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/635default union field does not work2024-02-02T17:08:50ZLevente Erősdefault union field does not work## Summary
Union field shall be able to be annotated as @default. In this case, a union data element can be assigned a value without explicitly identifying the field name. Titan does not support this right now.
## Steps and/or TTCN-3 c...## Summary
Union field shall be able to be annotated as @default. In this case, a union data element can be assigned a value without explicitly identifying the field name. Titan does not support this right now.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following contents:
```
type union myut{
@default
integer field1,
charstring field2
}
testcase union_def() runs on ct_empty{
var myut v;
v.field1 := 1;
v.field2 := "a";
v := {field1:=2};
v := {field2:="b"};
//v := 3; //error
v.field1 := 3;
v := 4;
if(v.field1==4){setverdict(pass);}
}
```
Compile.
## What is the current bug behavior?
Titan does not recognize the @default annotation.
## What is the expected correct behavior?
The above code should run and pass. When the (uncommented) v:=3 row is processed, it should yield an error, as value assignment is only possible without identifying the union field if the default field is the chosen field at that point in time. For the same reason, the v := 4 row should not cause an error, as right before it field1 was chosen.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/634inner type unreachable with 2D record of integer2024-02-06T15:31:39ZLevente Erősinner type unreachable with 2D record of integer## Summary
After creating a 2-dimensional integer array type, the innermost type is unreachable with the [-] notation
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record length (10) of record length (1...## Summary
After creating a 2-dimensional integer array type, the innermost type is unreachable with the [-] notation
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record length (10) of record length (10) of integer Matrix;
type record of integer ROI;
const ROI[-] c := 1;
const Matrix[-][-] c_MyInnermostInt := 1;
```
## What is the current bug behavior?
```ROI[-]``` resolves to integer, but ```Matrix[-][-]``` results in an error
## What is the expected correct behavior?
```Matrix[-][-]``` should resolve to integer.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/626value list notation for set types is not working2024-02-07T13:47:02ZLevente Erősvalue list notation for set types is not working## Summary
Using value list notation when assigning value to a set type data element results in an error, while according to the TTCN-3 standard, section 6.2.0 it is legal.
## Steps and/or TTCN-3 code to reproduce
```
type set mySet{
...## Summary
Using value list notation when assigning value to a set type data element results in an error, while according to the TTCN-3 standard, section 6.2.0 it is legal.
## Steps and/or TTCN-3 code to reproduce
```
type set mySet{
integer field1,
charstring field2
}
testcase list_notation_set() runs on ct_empty{
var mySet v := {1,"a"};
}
```
Try to compile the above code placed in the module.
## What is the current bug behavior?
Error is produced: Value list notation cannot be used for set type `@datatypes.mySet'
## What is the expected correct behavior?
code should compile as if the assignment was done like:
```
var mySet v := {field1:=1,field2:="a"};
```
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwtBotond BaranyiBotond Baranyi