Doc update for 3.3.0

Author: mattias-mohlin

docs-sources/building/art-compiler.md

@@ -65,7 +65,9 @@ A build configuration is useful when you want to build a TC that uses [build var
 Specifies a Build Variants script to use for the build. Read more about build variants [here](build-variants.md). 
 
 ### clean
-If this option is set, the Art Compiler will perform a clean build by first removing the output folder if it already exists (as a result of a previous build). Clean builds take longer to perform since all C++ files have to be regenerated and recompiled. Normally you don't need to do a clean build, but in some cases it may be necessary. For example, if you are using [Build Variants](build-variants.md) and have changed the [build configuration](build-variants.md#build-configuration), then a clean build is recommended to ensure that all changes are picked up by the build. If you do a clean build, but the output folder for some reason cannot be deleted, then the build will fail. A typical situation when this happens is when the built executable is running because you forgot to terminate it. If the executable is running it cannot be deleted, and hence the output folder also cannot be deleted.
+If this option is set, the Art Compiler will perform a clean build by first removing the output folder that is specified by the built TC, if that folder exists (as a result of a previous build). Output folders of prerequisite TCs will be removed too. This ensures that the build will rebuild everything. 
+
+Clean builds take longer to perform since all C++ files have to be regenerated and recompiled. Normally you don't need to do a clean build, but in some cases it may be necessary. For example, if you are using [Build Variants](build-variants.md) and have changed the [build configuration](build-variants.md#build-configuration), then a clean build is recommended to ensure that all changes are picked up by the build. If you do a clean build, and a output folder exists but for some reason cannot be deleted, then the build will fail. A typical situation when this happens is when the built executable is running because you forgot to terminate it. If the executable is running it cannot be deleted, and hence the output folder also cannot be deleted.
 
 !!! note
     If you only want to remove binaries produced by make, and not the generated source files, you can instead run `make clean`. This makes the subsequent build slightly faster since not all C++ files need to be regenerated.

docs-sources/building/index.md

@@ -23,7 +23,7 @@ To perform the third step (running make to generate binaries) you can simply go
 The context menu of a TC provides a few useful commands that automate some of the steps mentioned above:
 
 * **Build**
-This command first generates C++ code and a make file for the TC, and then runs the make tool on the generated make file. Note, however, that this command does not set the TC as active. If you plan to change code snippets in generated code you must set the TC as active yourself.
+This command first generates C++ code and a make file for the TC, and then runs the make tool on the generated make file. Note, however, that this command does not set the TC as active. If you plan to [change code snippets in generated code](#making-changes-in-generated-c) you must set the TC as active yourself.
 
 * **Run**
 First builds the TC, and then attempts to launch the executable that is produced. The executable is launched in a non-debug mode by specifying the launch argument `-URTS_DEBUG=quit`. If you want to launch the executable in a different way, for example with different command-line arguments, you can go to the Terminal and manually launch it from there. Note that if your TC creates a library rather than an executable, then this command will still build the TC, but will then give an error message since there is no executable to run. 
@@ -32,7 +32,7 @@ First builds the TC, and then attempts to launch the executable that is produced
     For a more flexible way of launching a built executable, either for running or debugging it, use a [launch configuration](../running-and-debugging/launch-configurations.md).
 
 * **Clean**
-Removes the target workspace folder produced when building a TC. This means that all generated C++ code, the make file, as well as any produced binaries will be removed. If you only want to remove the binaries you can instead go to the Terminal and invoke `make clean` to clean using the make file.
+Removes the target workspace folder produced when building a TC. If the TC has [prerequisites](transformation-configurations.md#transformation-configuration-prerequisites) they will be cleaned too. This means that all generated C++ code, the make file, as well as any produced binaries will be removed. If you only want to remove the binaries you can instead go to the Terminal and invoke `make clean` to clean using the make file.
 
 If you build a TC and at least one error exists in the TC itself, in prerequisites TCs or in any of the Art files that will be built, then a dialog will ask if you want to cancel the build (recommended) or proceed anyway (only do this if you are confident the errors are safe to ignore).
 

docs-sources/running-and-debugging/tracing.md

@@ -92,11 +92,12 @@ While a sequence diagram can be useful for showing an overview of the run-time i
 
 The textual representation of a trace uses a domain specific tracing language, where each line tell about something that happens in the application at run-time:
 
-* Tracing starts. Comments are then printed at the beginning of the `.art-trace` file to show the [trace configuration](#trace-configuration) that will be used for the trace. Other information is also printed, for example the current time (according to the chosen [timestamp precision](#timestamp-precision) and the name of the running application).
+* Tracing starts. Comments are then printed at the beginning of the `.art-trace` file to show the [trace configuration](#trace-configuration) that will be used for the trace. Other information is also printed; the current time (according to the chosen [timestamp precision](#timestamp-precision)), the name of the running application and the command-line arguments for the application.
 
 ``` cpp
 // "trace": {
 //     "application": "Top.EXE"
+//     , "args": ["-URTS_DEBUG=quit"]
 //     , "start_time": "2025-11-13 16:32:40.435320100"
 // }
 ```

docs-sources/target-rts/versions.md

@@ -45,7 +45,7 @@ Below is a table that lists all changes made in the TargetRTS since version 8000
 | 8014 | [Shorter state qualifiers in the RTSDebugger system command](#shorter-state-qualifiers-in-the-rtsdebugger-system-command) <br> [New RTLock utility](#new-rtlock-utility) <br> [Printing 64 bit integers in RTFormat](#printing-64-bit-integers-in-rtformat) <br> [More information for messages when tracing](#more-information-for-messages-when-tracing) <br> [Error code for circular import](#error-code-for-circular-import) <br> [Unparse and merge of RTJsonResult](#unparse-and-merge-of-rtjsonresult) <br> [Removal of support for .ms trace format](#removal-of-support-for-ms-trace-format) <br> [Trace configuration and timestamps](#trace-configuration-and-timestamps) |
 | 8015 | [RTLogStream performance improvements](#rtlogstream-performance-improvements) <br> [Tracing of synchronous messages](#tracing-of-synchronous-messages) <br> [Extended RTTracer API](#extended-rttracer-api) <br> [Include the `time2_receive` timestamp by default in traces](#include-the-time2_receive-timestamp-by-default-in-traces) <br> [Configuration of trace file name](#configuration-of-trace-file-name) <br> [Thread information for traced instances](#thread-information-for-traced-instances) <br> [Removed C++ 14 flag for Clang target configurations](#removed-c-14-flag-for-clang-target-configurations) |
 | 8016 | [Startup synchronization of RTTimerActor](#startup-synchronization-of-rttimeractor) <br> [Port full warning](#port-full-warning) |
-| 8017 | [Improvements in RTTracer::note()](#improvements-in-rttracernote) |
+| 8017 | [Improvements in RTTracer::note()](#improvements-in-rttracernote) <br> [Run-time error checks for port connections](#run-time-error-checks-for-port-connections) <br> [Inclusion of program arguments in trace configuration](#inclusion-of-program-arguments-in-trace-configuration) |
 
 ### JSON decoder
 A new decoder class [`RTJsonDecoding`](../targetrts-api/class_r_t_json_decoding.html) is now available for decoding messages and data from JSON. JSON produced from data by the JSON Encoder ([`RTJsonEncoding`](../targetrts-api/class_r_t_json_encoding.html)) can be decoded back to (a copy of) the original data.
@@ -208,3 +208,10 @@ A new configuration setting [PORTFULL_WARNING](build.md#portfull_warning) is now
 
 ### Improvements in `RTTracer::note()`
 The function [RTTracer](../targetrts-api/class_r_t_tracer.html)::note() now takes a `const std::string&` parameter instead of a `const char*`. Also, a note is not printed if tracing is currently disabled.
+
+### Run-time error checks for port connections
+A few defensive null pointer checks, and the printing of run-time errors, have been added in code that uses port connections. For example, the code can now cope with a situation where a connected port is dangling without an owner. Under normal circumstances these scenarios are not expected, but should they anyway occur these checks and run-time errors can help the troubleshooting.
+
+### Inclusion of program arguments in trace configuration
+The comment with the trace configuration at the beginning of an `.art-trace` file now contains an "args" array with the command-line arguments for the traced application.
+