Documented some recent changes in the reference guide (#742, #745)

Signed-off-by: Botond Baranyi <botond.baranyi@ericsson.com>

usrguide/referenceguide/4-ttcn3_language_extensions.adoc

@@ -1407,7 +1407,7 @@ Differences from the legacy method:
 * ASN.1 types automatically have `BER`, `JSON`, `PER`, and XML (if the compiler option `-a` is set) encoding (they are treated as if they had the corresponding `encode` attributes);
 * encoding-specific `variant` attributes are supported (e.g.: `variant "XML"."untagged"`);
 * the parameters `encoding_info/decoding_info` and `dynamic_encoding` of predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` are supported (the `encoding_info`/`decoding_info` parameters are currently ignored, see also the next point)
-* the `dynamic_encoding` parameter can be used for choosing the codec to use for values of types with multiple encodings, the following values are available: `BER:2002`, `CER:2002`, `DER:2002`, `JSON`, `OER`, `RAW`, `TEXT`, `XER`, `XML` and `PER`; 
+* the `dynamic_encoding` parameter can be used for choosing the codec to use for values of types with multiple encodings, the following values are available: `BER:2002`, `CER:2002`, `DER:2002`, `JSON`, `OER`, `RAW`, `TEXT`, `XER`, `XML`, `PER` (for unaligned basic PER), `PER:ALIGNED` (for aligned basic PER), `PER:CANONICAL` (for unaligned canonical PER) and `PER:CANONICAL ALIGNED`; 
 * the `self.setencode` version of the `setencode` operation is supported (it can be used for choosing the codec to use for types with multiple encodings within the scope of the current component);
 * the `@local` modifier is supported for `encode` attributes;
 * a type's the default codec (used by `decmatch` templates, the @decoded modifier, and the predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` when no dynamic encoding parameter is given) is:
@@ -8596,61 +8596,36 @@ Currently the only limitation is that function reference types cannot have lazy
 
 The Function Test runtime sometimes provides extra features that the default Load Test runtime doesn't (due to it being optimized for performance). One of these features, negative testing for encoders, was already discussed <<build-consistency-checks, here>>.
 
-=== Referencing record of elements through function parameters
+=== Referencing elements of `record of` component variables through function parameters
 
-Passing a `record of` and one (or more) of its elements as `out` and/or `inout` parameters of the same function means that changes made inside the function to either of these parameters can cause changes in the others. Lowering the size of the `record of` (inside the function) can cause some of the other parameters to become `unbound` (this functionality only works in the Function Test runtime).
+One or more elements of a `record of`, `set of` or array component variable can be passed as `inout` parameters to a function or altstep, where that component variable is visible. In this case changes made inside the function to either of these parameters or to the component variable can cause changes in the others. Lowering the size of the `record of`/`set of` (inside the function) can cause some of these parameters to become `unbound` (this functionality only works in the Function Test runtime).
 
 Example:
 [source]
 ----
 type record of integer RoI;
-function f_param_ref(inout RoI p_roi, inout integer p_ref)
+
+type component CT {
+  var RoI cv_roi := { 1, 2, 3, 4, 5 };
+}
+
+function f_param_ref(inout integer p_ref) runs on CT
 {
-  p_roi := { 10 };
+  cv_roi := { 10 };
   log(p_ref);      // <unbound>
   p_ref := 20;
-  log(p_roi);      // { 10, <unbound>, <unbound>, 20 }
+  log(cv_roi);     // { 10, <unbound>, <unbound>, 20 }
 }
 ...
 // function call:
-var RoI v_roi := { 1, 2, 3, 4, 5 };
-f_param_ref(v_roi, v_roi[3]);
+f_param_ref(cv_roi[3]);
 
 ----
 
-This also works if the `record of` or its element(s) are embedded into other structures, and these structures are passed as the function's parameters. It also works if the `record of` is an `optional` field of a `record` or `set`, and the field is set to `omit` inside the function.
+This also works if the `record of`/`set of`/array is embedded into another structured component variable, or if the referenced elements are embedded into other structures, and these structures are passed as the function's parameters. It also works if the `record of`/`set of`/array is an `optional` field of a `record` or `set`, and the field is set to `omit` inside the function.
 
 This functionality does not work for templates.
 
-WARNING: a side effect of this feature is that, in the Function Test runtime, passing an element outside of the record of's bounds as an `out` or `inout` parameter does not extend the record of if the function doesn't change the parameter, instead the size of the `record of` will remain unchanged. In the Load Test runtime this would change the size of the `record of` to the value of the index, and the `record of` would contain unbound elements at its end.
-
-Example (filling an array up by passing the element after the last as a function parameter):
-[source]
-----
-type record of integer RoI;
-function f_fill_array(out integer p_elem, in integer p_val) return boolean
-{
-  if (p_val < 3) {
-    p_elem := p_val;
-    return true;
-  }
-  return false;
-}
-
-...
-// the function call:
-var integer v_val := 0;
-var RoI v_roi := { };
-while (f_fill_array(v_roi[sizeof(v_roi)], v_val)) {
-  v_val := v_val + 1;
-}
-// Results:
-// In the Function Test runtime the array would contain { 0, 1, 2 } and its
-// sizeof would return 3
-// In the Load Test runtime the array would contain { 0, 1, 2, <unbound> }
-// and its sizeof would return 4
-----
-
 [[compatibility_of_record_of_types]]
 === Compatibility of record of types