1.4.32. Migration to 7.6.0

1.4.32.1. axivion_config / axivion_ci

All configuration options below /Results/Database have been moved into /Results/Dashboard and the rule /Results/Database does not exist any more. This means, that e.g. /Results/Database/ci_mode/directory is now called /Results/Dashboard/ci_mode/directory.

No action needs to be taken for JSON configuration files, they will be migrated on the fly when they are loaded. The result of this automatic migration will only be written to the JSON files on the next edit with axivion_config. Python configuration files cannot be migrated automatically, so some manual migration might be necessary there.

Caution

JSON configuration files contain version information in the _VersionNum key that is essential for automatic migration. In case that information has been removed for some reason, the automatic migration cannot be performed, so the files have to be migrated manually to avoid configuration loading errors.

1.4.32.2. axivion_analysis

When using axivion_analysis with the --rule argument, note that version 7.6 subtly changes the behavior: in version 7.5 and earlier, --rule implicitly disabled all other rules (activated in the current configuration, or even those that are implicitly active like those in /Analysis/AnalysisControl/Environment/Externals). In version 7.6, --rule implicitly acts as if --limit_to AnalysisControl was specified. This means that any rules within the AnalysisControl subtree will remain active. You can override this behavior by explicitly using the --limit_to switch.

This change also impacts test cases using // test: analysis(['SomeRule']). For example, tests that previously did not use StaticSemanticAnalysis will now use it if it is enabled in the configuration.

1.4.32.3. perform_tests

perform_tests no longer supports the old XML-based test format (.tst file extension). You will need to migrate these tests to the Source Test File Format. This migration can be partially automated with the migrate tst_tests tool, see migrate tst_tests --help for more details.

1.4.32.4. Semantic Analysis Scripting

Rules referring to issues reported from semantic analysis now use named instead of positional message arguments. If you have written your own rules using semantic analysis error messages, or if you have redefined messages of existing semantic analysis rules, then it might be necessary to switch to the named message arguments in your code/configuration.

1.4.32.5. Semantic Analysis

Treatment of heap objects coming from a void* allocation with no immediate conversion to a different type has been improved. The option allow_all_heap_types is therefore no longer needed and has been removed.

1.4.32.6. Dashboard

Dashboard API version strings

The keyword NOW of the version date grammar has been deprecated and changed to mean the same as LATEST. Scripts should be updated accordingly.

Dashboard API version names

The AnalysisVersion.name field is now deprecated because of unclear timezone of the included timestamp. A removal is not planned.

There is now a new optional field AnalysisVersion.label that contains the value of the environment variable AXIVION_VERSION_NAME at analysis time and that together with the well defined timestamp fields can be used to represent versions more accurately / flexibly.

Generic Rules Documentation

The HTML-documentation of the Generic Stylecheck-rules that was accessible via the URL /rules has been removed. Rule documentation of all shipped rules, including the Generic rules has long been available in the comprehensive documentation.

1.4.32.7. Stylechecks

CodingStyle-NoWhitespacePointerReference

This rule as been extended by various options to control where no, a single, or any whitespace should be used. Using these options the rule CodingStyle-NoWhitespacePointerReferenceInverse becomes obsolete and may be removed in a future version.

MisraC2012 Amendment 3

Due to the changes in MisraC2012 Amendment 3, the message keys no_noreturn, no_generic_selection and no_alignment have been removed from rule MisraC2012-1.4. The rule will not produce these messages anymore. Furthermore, rule MisraC2012-21.12 has a new default severity of required and prohibits the usage fenv.h completely. In consequence, the option forbidden_libheader_symbol_use has been removed from the rule.

CQM-GodNamespace and CQM-Namespacelet

The default value of the option count_templates was changed from False to True for both rules.

FaultDetection-ExceptionSpecificationViolation, FaultDetection-NoexceptViolations, AutosarC++ rule A15.4.4, CertC++-ERR55, MisraC++-15.5.3

The misspelled option ignore_unkown_routines has been corrected to ignore_unknown_routines. Existing configuration files setting this option are migrated on the fly when they are loaded. The fixed option name is saved permanently when editing a configuration file in axivion_config.

FaultDetection-UninitializedVariable

In rules detecting uninitialized variables like FaultDetection-UninitializedVariable, CertC-EXP33, CWE-Pointer-Issues-119, MisraC2012Directive-4.1, MisraC2019Directive-4.1, MisraC2023Directive-4.1, MisraC-9.1, MisraC2012-9.1, AutosarC++18_03-A8.5.0, AutosarC++18_10-A8.5.0 and AutosarC++19_03-A8.5.0, the option assume_parameters_are_initialized has been removed: if rhs in the assignment arr[i] = rhs is uninitialized, the rule already reports a finding for rhs or one of its predecessors in the data flow. For this reason, the analysis now considers the assignment to arr[i] = rhs always as writing an initialized value to arr[i], thus avoiding propagated reports of uninitialized values (as it is already the case for non-array variables). Hence assume_parameters_are_initialized is no longer required.

1.4.32.8. cafeCC

The interpretation of the --no_bodies_for_path= and --no_macros_for_path= switches has changed slightly: previously the glob patterns specified for these options were checked against the absolute paths of the source files, now instead it applies to the paths as they are stored in the IR and displayed in the dashboard: relative to the project base path, or absolute if the file was outside the project base path.

1.4.32.10. IR

In the physical IR, the classes Friend_Composite_Declaration, Unqualified_Friend_Composite_Declaration and Qualified_Friend_Composite_Declaration have been replaced with Friend_Type_Declaration. The befriended type is available with the new The_Type edge and now properly includes template arguments.

In the physical IR, selections of extended float types have been combined into a single class:

Mapping of old PIR class names to new PIR class names

Old name

New name

C_Float16_Type_Selection

C_Extended_Float_Type_Selection

C_Float80_Type_Selection

C_Extended_Float_Type_Selection

C_Float128_Type_Selection

C_Extended_Float_Type_Selection

C_Imaginary_Float80_Type_Selection

C_Imaginary_Extended_Float_Type_Selection

C_Imaginary_Float128_Type_Selection

C_Imaginary_Extended_Float_Type_Selection

C_Complex_Float80_Type_Selection

C_Complex_Extended_Float_Type_Selection

C_Complex_Float128_Type_Selection

C_Complex_Extended_Float_Type_Selection

Check the .Logical edge of the new “extended” selection to distinguish between the different types. Note that our compiler now supports _Float16, __fp16 and __bf16 as three distinct floating-point types, and that _Float16 can now be combined with the _Complex and _Imaginary modifiers.

In the logical IR, imaginary and complex types have been simplified: all C_Imaginary_*_Type classes are now replaced with Imaginary_Type. The new Imaginary_Type.Based_On edge refers to the underlying floating-point type. For complex types, all C_Complex_*_Type classes are replaced with Complex_Type.

Floating-point types in the logical IR no longer offer Min and Max fields. They instead store the number of mantissa bits and the exponent range.

1.4.32.11. Gravis

Version 7.5 officially dropped support for XML configuration files (*.config). Nevertheless, in all 7.5.x releases, Gravis still honored the settings in existing gravis2.config files (for instance, inside $(HOME)/.bauhaus), as long as there were no new-style Gravis settings in $(HOME)/.bauhaus/gravis.json or in any other JSON configuration file referenced by BAUHAUS_CONFIG.

This legacy support has been deprecated since version 7.3 and has finally been dropped, so starting from version 7.6, Gravis only reads settings from JSON configuration files. If you still rely on Gravis settings in a .config file, you either need to migrate the file to the new system using the migrate gravis facility (see Migrating Gravis for details) or recreate the configuration from scratch in axivion_config. Please note that the migrate gravis facility is only available in versions 7.3 to 7.5.

The option --config has been removed and trying to use it causes an error. This option was only relevant for the obsolete XML configuration system.

Caution

Gravis still reads SVG files from the custom_icons subdirectory of each directory listed in BAUHAUS_CONFIG and automatically associates them with node types matching their file names, but this behavior is deprecated and may be removed in a future release. See Adding SVG Icons for setting up explicit references to SVG files from configuration files.

Note

Gravis still reads menu scripts from the gravis_scripts subdirectory of each directory listed in BAUHAUS_CONFIG and this is still the only supported way of adding scripted menu entries to Gravis (see Adding Scripts to Menus, Shortcuts and Events).