1.4.40. Migration to 7.5.0¶

Caution

Dropping of Old Configuration System and Deprecated Tools

Release 7.5.0 is the first that does no longer support the old project configuration (e.g. build.conf or XML files *.config).

You have to migrate to the New Configuration System first to be able to use release 7.5.0 (see Migration to new Configuration System for details).

Therefore, several deprecated command-line tools have also been dropped in this release. The functionality they provided is still available via axivion_ci and axivion_analysis and the corresponding rules.

The tools that have been dropped are:

bauhaus_config

cibuild

incprof

ir2rfg

iranalysis

irclones

stylecheck

For convenience reasons there now exists a new tool ir2rfg which emulates basic usage of old ir2rfg but does not provide all command-line arguments ir2rfg used to.

1.4.40.1. Configuration¶

Relative paths on BAUHAUS_CONFIG where previously made absolute by prepending the location of the Axivion Suite installation directory. This is no longer the case, instead relative paths on BAUHAUS_CONFIG are interpreted relative to the current working directory. If your setup used relative paths to references files or directories relative to the Axivion Suite installation directory, please make sure to inject appropriate prefixes.

Using relative paths on BAUHAUS_CONFIG can lead to undesired effects if the build system you are using changes the working directory.

1.4.40.2. IR¶

The IR part AIR (also known as Analysis IR or part_analyses) has been removed. It was only used by old tools like iranalysis which no longer exist. Analysis results being usable by subsequent analyses/checks are available inside the analysis framework in axivion_analysis.

The IR part LIR (also known as Logical IR or part_logical) has seen some minor design changes: the classes Nothrow_Function and Throw_Function were merged into the new class Ordinary_Function. The following table maps old class names to new class names for the most commonly used types. If you have custom rules using these names, you will need to adjust your rules (usually search+replace will be sufficient).

Mapping of old LIR class’ names to new LIR class names¶
Old name (nothrow)	Old name (throw)	New name
Nothrow_Function	Throw_Function	Ordinary_Function
Template_Nothrow_Function	Template_Throw_Function	Template_Function
Static_Nothrow_Function	Static_Throw_Function	Ordinary_Static_Function
Nothrow_Method	Throw_Method	Ordinary_Method
Template_Nothrow_Method	Template_Throw_Method	Template_Method
Nothrow_Static_Method	Throw_Static_Method	Ordinary_Static_Method
Nothrow_Constructor	Throw_Constructor	Ordinary_Constructor
Nothrow_Destructor	Throw_Destructor	Ordinary_Destructor

Additionally, a number of LIR Instruction node types have been removed, e.g. Size_Of_Instruction, Real_Part_Instruction, Imaginary_Part_Instruction. The effect of these instructions are now represented with lower-level instructions such as integer literals or complex accesses via indexing operands. This reduces the number of instruction types that analyses need to handle.

1.4.40.3. Continuous Integration¶

CMakeIntegration¶

The rule CMakeIntegration (introduced in 7.3.9 for the 7.3 release series and in 7.4.3 for the 7.4 release series) has undergone a major overhaul for providing easier usability and a better default out of the box. While effort has been made to maintain compatibility with existing configurations, we cannot guarantee that each and every possible configuration still works without changes. Please check your project configuration after upgrading to 7.5.0 if you are already using the CMakeIntegration build system rule.

1.4.40.4. Stylechecks¶

Preview of MISRA C++:202X rules¶

This release contains a preview for a subset of rules contained in the upcoming new MISRA C++ standard. The intention of these rules is to collect feedback about their impact on real-world code before the standard will be published. The current rule names are mandated by MISRA and will have to change once the standard is published, which means configurations and code annotation comments referring to the current rule names will have to be migrated then as well.

Compile-time constants in FaultDetection-IntegerOverflow and derived rules¶

Rule FaultDetection-IntegerOverflow does not check for overflows in compile-time constants by default anymore. You can restore the old behavior by setting relevant_expressions to const_expressions_only. To disable checks both for const-expressions and compile-time constants you can set the option to none. The derived rules AutosarC++-A4.7.1, CertC-INT31, CertC++-INT31, CWE-Numeric-Errors-190, CWE-Numeric-Errors-191 and CWE-Numeric-Errors-192 retained the old behavior as they define certain exceptions, or they should be consistent with other rules from the same standard. The derived rules MisraC-21.1, MisraC2012Directive-4.1 and MisraC++-0.3.1 retained the old behavior in order not to produce duplicated messages with other Misra rules that check for overflows in compile-time constants. For the derived rules, set relevant_expressions to const_and_compile_time_constant to enable the additional check for overflows in compile-time constants.

Option `abstract_interpretation_maximal_tracked_array_index` in FaultDetection-IntegerOverflow and FaultDetection-DivisionByZero¶

The behavior controlled by option abstract_interpretation_maximal_tracked_array_index of rules FaultDetection-IntegerOverflow and FaultDetection-DivisionByZero changed.

Depending on your project, it might be necessary to increase the value of this options to prevent false positives.

Before, the value defined the maximal index of array index expressions tracked by the additional Symbolic Expression Analysis, i.e., a value of 2 would let the analysis track values a[0], a[1], a[2] of any array a. Now, the option bounds the number of different array index expressions per routine. A value of 2 lets the analysis track the first two different array index expressions it encounters in a routine. Consider the following example.

extern signed char a[6];
extern signed char x;
int main()
{
    if (a[2] &lt; 0)
    {
        x = x / a[2];
    }
    if (a[3] &lt; 0)
    {
        x = x / a[3];
    }
    if (a[4] &lt; 0)
    {
        x = x / a[4];
    }
    return 0;
}

In this routine, the analysis would track the values of a[2] and a[3], as they occur first. Hence, FaultDetection-DivisionByZero can infer that the first two divisions cannot occur. The third is reported, because a[4] is not tracked anymore.

Note that the new behavior distinguishes between different arrays, while the old one treated all equally. This allows a more consistent performance, but may require you to increase these options if your projects use many arrays per routine.

Finally, the default value of these options changed from 2 to 10 as well.

Option `inspect_class_field_moves` in AutosarC++-A12.8.3¶

The option inspect_class_field_moves has been removed from rule AutosarC++-A12.8.3. Instead, the rule now automatically inspects moves of more involved objects (e.g., class fields) if StaticSemanticAnalysis is activated. Otherwise, it works in a more restricted mode and will not detect reads-after-move of these objects. This is consistent with the original implementation, since StaticSemanticAnalysis was needed anyway in case inspect_class_field_moves was enabled.

Resource renaming in MisraC2012-21.20¶

Rule MisraC2012-21.20 changed the names for resources. TextualTime replaces the former resources AscTimeInformation and CTimeInformation, because the functions ctime and asctime shall be treated as if they are the same function. CalendarTime replaces the former resources GmTimeInformation and LocalTimeInformation because the functions gmtime and localtime shall be treated as if they are the same function.

This also changes the names of the rules that allow these resources to be configured (e.g., to change the allocator/deallocator functions). Existing settings are mapped to the new rules automatically when they are loaded. We recommend reviewing the results of the automatic migration if any of the resources mentioned above were used with non-default settings.

Option `avoid_uncertain_messages` in Generic-LocalInclude and AutosarC++-A16.2.2¶

The option avoid_uncertain_messages of rules Generic-LocalInclude and ÀutosarC++-A16.2.2 had previously been overwritten by the same option in file includes.config. This is no longer the case (there is no support for includes.config anymore). To get back the old set of messages, you can set avoid_uncertain_messages to false.

Custom stylecheck rules derived from `bauhaus.style.rule.Rule` or `AxivionCustomerRule`¶

Custom stylecheck rules derived from bauhaus.style.rule.Rule or AxivionCustomerRule are no longer supported and must be migrated to axivion.analysis.AnalysisRule. The command migrate 7_0 can partially automate this migration.

Severity of MisraC++-0.3.1¶

The severity of rule MisraC++-0.3.1 was changed from required to document as originally documented but wrongly given in earlier versions. This may impact overall test requirements.

Option `check_only_first_character` in CertC-DCL16¶

The default value of option check_only_first_character in rule CertC-DCL16 was corrected to true to match the documentation. Fewer violations may be reported.

1.4.40.5. Metrics¶

The option count_activator_comments of metrics in the group CommentMetrics has been removed. It was no longer functional since activator comments have been replaced by the more general code annotation feature.

1.4.40.6. Qualification Kit¶

The qualification kit folder “iranalysis” was renamed to “errorchecks”.

1.4.40.7. Axivion Eclipse Plugin¶

The minimum required version to run the Axivion Eclipse Plugin plugin is raised to 4.5.0 (Mars R). The plugin will not run with 4.2 (Juno) anymore.

1.4.40.8. Axivion Visual Studio Plugin¶

The minimum required version to run the Axivion Visual Studio Plugin has been raised to Visual Studio 2015 (14.0). The plugin will not run with Visual Studio 2010 (10.x), 2012 (11.x), or 2013 (12.x) anymore.

1.4.40.9. Axivion Visual Studio Code Plugin¶

The minimum version of Visual Studio Code supported by the Axivion Visual Studio Code Plugin was raised to 1.66.0.

1.4.40.10. Rhapsody Import (rpy2rfg)¶

The support for 32 bit Rhapsody has been removed. rpy2rfg needs a 64 bit Rhapsody (which uses a 64 bit JVM) to run.

1.4.40.11. rm_branch_dbs¶

Since version 7.2.3 we supply a tool called rm_branch_dbs to be called periodically (i.e. once per day) by some task scheduler on the central dashboard host in order to clean up databases for Git branches that no longer exist.

Previously a lot of parameters had to be supplied to the tool rm_branch_dbs even though some information could be read from the project databases themselves.

This has now been improved, but at the cost of changed command line syntax. Therefore, if you use rm_branch_dbs you need to adjust your periodic call to the new command line syntax.

1.4.40.12. Dashboard Reporting¶

Local imports now must be relative¶

The Reporting Framework Version was increased from 2.2 to 3.0 which brings with it a change in how reporting modules need to specify their local imports, i.e. imports of non-report-python-files inside the report modules folder. Note, that this does not affect imports of 3rd-Party python packages like e.g. reportlab. This change is done in order to reduce the chance of name conflicts and to match behavior with the stylecheck framework.

So if you had the following files in your report module folder:

report_custom.py
library.py

and inside report_custom.py did

...
import library
...

you will now need to change that statement to

...
from . import library
...

and to increase the target framework version of the module to 3.0.

Should you have the need of running your modules with the new Axivion Suite and an older one at the same time, you can do so by not doing the migration steps outlined above but instead manually extending sys.path from inside the module:

import os,sys
sys.path.insert(0, os.path.dirname(__file__))

report_runner CLI arguments¶

The report_runner script has undergone some breaking changes in its command-line interface:

The module is not given before the subcommand any more but after the subcommands switches and before the module options

The parameter modules_dir has been completely removed

The module options are not given as JSON any more but in a more command-line compatible way

Previously, the –verbose switch only was an alias for –stacktrace which since 7.3.1 is the preferred way of enabling or disabling stack trace printing on unsuccessful script termination. Now, the –verbose switch has its own purpose again, which is triggering additional debug output.

Some examples of before:

(1) report_runner --module_file path/to/report_example.py create --input options.json
               string_option=\"value\"

(2) report_runner --module_file path/to/report_example.py create --input options.json
               list_option=\[\"value1\", \"value2\"\]

(3) report_runner --module_file path/to/report_example.py create --input options.json
               list_elem_option=\"value1\" list_elem_option=\"value2\"

(4) report_runner --modules_dir path/to/modules_dir --module report_example options
               --format json

and after:

(1)     report_runner create --input options.json
               path/to/report_example.py string_option=value

(2) (3) report_runner create --input options.json
               path/to/report_example.py list_option=value1,value2

(4)     report_runner options --format json path/to/modules_dir/report_example.py

1.4.40.13. Dashboard¶

Main Dashboard URL¶

The setting for the Dashboard URL on the General Settings page has moved to the top. The auto-detection now won’t consider the current request URL any more in order to guess the desired self-reference URI which may lead to some wrong URIs in erosion notification mails in case the setting is unconfigured. The general recommendation is to configure the value, especially if your desired hostname is different from localhost or the Dashboard is running behind a proxy.

Dashboard Page¶

The Dashboard Page is no longer individually configurable for each user and each project. Now there is only one configuration of the page that can be modified by any user with the Administrate permission.

Axivion Suite 7.12.0

Navigation

1.4.40. Migration to 7.5.0¶

1.4.40.1. Configuration¶

1.4.40.2. IR¶

1.4.40.3. Continuous Integration¶

CMakeIntegration¶

1.4.40.4. Stylechecks¶

Preview of MISRA C++:202X rules¶

Compile-time constants in FaultDetection-IntegerOverflow and derived rules¶

Option `abstract_interpretation_maximal_tracked_array_index` in FaultDetection-IntegerOverflow and FaultDetection-DivisionByZero¶

Option `inspect_class_field_moves` in AutosarC++-A12.8.3¶

Resource renaming in MisraC2012-21.20¶

Option `avoid_uncertain_messages` in Generic-LocalInclude and AutosarC++-A16.2.2¶

Custom stylecheck rules derived from `bauhaus.style.rule.Rule` or `AxivionCustomerRule`¶

Severity of MisraC++-0.3.1¶

Option `check_only_first_character` in CertC-DCL16¶

1.4.40.5. Metrics¶

1.4.40.6. Qualification Kit¶

1.4.40.7. Axivion Eclipse Plugin¶

1.4.40.8. Axivion Visual Studio Plugin¶

1.4.40.9. Axivion Visual Studio Code Plugin¶

1.4.40.10. Rhapsody Import (rpy2rfg)¶

1.4.40.11. rm_branch_dbs¶

1.4.40.12. Dashboard Reporting¶

Local imports now must be relative¶

report_runner CLI arguments¶

1.4.40.13. Dashboard¶

Main Dashboard URL¶

Dashboard Page¶

1.4.40. Migration to 7.5.0¶

1.4.40.1. Configuration¶

1.4.40.2. IR¶

1.4.40.3. Continuous Integration¶

CMakeIntegration¶

1.4.40.4. Stylechecks¶

Preview of MISRA C++:202X rules¶

Compile-time constants in FaultDetection-IntegerOverflow and derived rules¶

Option abstract_interpretation_maximal_tracked_array_index in FaultDetection-IntegerOverflow and FaultDetection-DivisionByZero¶

Option inspect_class_field_moves in AutosarC++-A12.8.3¶

Resource renaming in MisraC2012-21.20¶

Option avoid_uncertain_messages in Generic-LocalInclude and AutosarC++-A16.2.2¶

Custom stylecheck rules derived from bauhaus.style.rule.Rule or AxivionCustomerRule¶

Severity of MisraC++-0.3.1¶

Option check_only_first_character in CertC-DCL16¶

1.4.40.5. Metrics¶

1.4.40.6. Qualification Kit¶

1.4.40.7. Axivion Eclipse Plugin¶

1.4.40.8. Axivion Visual Studio Plugin¶

1.4.40.9. Axivion Visual Studio Code Plugin¶

1.4.40.10. Rhapsody Import (rpy2rfg)¶

1.4.40.11. rm_branch_dbs¶

1.4.40.12. Dashboard Reporting¶

Local imports now must be relative¶

report_runner CLI arguments¶

1.4.40.13. Dashboard¶

Main Dashboard URL¶

Dashboard Page¶

Option `abstract_interpretation_maximal_tracked_array_index` in FaultDetection-IntegerOverflow and FaultDetection-DivisionByZero¶

Option `inspect_class_field_moves` in AutosarC++-A12.8.3¶

Option `avoid_uncertain_messages` in Generic-LocalInclude and AutosarC++-A16.2.2¶

Custom stylecheck rules derived from `bauhaus.style.rule.Rule` or `AxivionCustomerRule`¶

Option `check_only_first_character` in CertC-DCL16¶