AOCL 2.2 changes - Majorly include LAPACK 3.9.0 support

.clang-format

@@ -0,0 +1,118 @@
+# Style file based on the modified rocBLAS / AOCL-Sparse style
+
+# Common settings
+BasedOnStyle:  WebKit
+TabWidth:        4
+IndentWidth:     4
+UseTab:          Never
+ColumnLimit: 100
+
+# Other languages JavaScript, Proto
+
+---
+Language: Cpp
+DisableFormat:   false
+Standard: Cpp11
+
+AccessModifierOffset: -4
+AlignAfterOpenBracket: true
+AlignConsecutiveAssignments: false
+AlignConsecutiveDeclarations: false
+AlignEscapedNewlines: Left
+AlignOperands:   true
+AlignTrailingComments: false
+AllowAllArgumentsOnNextLine: true
+AllowAllConstructorInitializersOnNextLine: true
+AllowAllParametersOfDeclarationOnNextLine: true
+AllowShortBlocksOnASingleLine: false
+AllowShortCaseLabelsOnASingleLine: false
+AllowShortFunctionsOnASingleLine: Empty
+AllowShortIfStatementsOnASingleLine: false
+AllowShortLoopsOnASingleLine: false
+AlwaysBreakAfterDefinitionReturnType: false
+AlwaysBreakAfterReturnType: None
+AlwaysBreakBeforeMultilineStrings: false
+AlwaysBreakTemplateDeclarations: true
+# If false, a function call’s arguments will either be all on the same line or will have one line each
+BinPackArguments: true
+# If false, a function call’s arguments will either be all
+# on the same line or will have one line each.
+BinPackParameters: true
+
+# Configure each individual brace in BraceWrapping
+BreakBeforeBraces: Custom
+# Control of individual brace wrapping cases
+BraceWrapping: {
+    AfterCaseLabel: 'true'
+    AfterClass: 'true'
+    AfterControlStatement: 'true'
+    AfterEnum : 'true'
+    AfterFunction : 'true'
+    AfterNamespace : 'true'
+    AfterStruct : 'true'
+    AfterUnion : 'true'
+    BeforeCatch : 'true'
+    BeforeElse : 'true'
+    IndentBraces : 'false'
+}
+
+CommentPragmas:   '^ IWYU pragma:'
+ConstructorInitializerAllOnOneLineOrOnePerLine: false
+ConstructorInitializerIndentWidth: 4
+ContinuationIndentWidth: 4
+Cpp11BracedListStyle: true
+SpaceBeforeCpp11BracedList: false
+DerivePointerAlignment: false
+ExperimentalAutoDetectBinPacking: false
+ForEachMacros:   [ foreach, Q_FOREACH, BOOST_FOREACH ]
+IndentCaseLabels: true
+IndentPPDirectives: None
+IndentWrappedFunctionNames: true
+KeepEmptyLinesAtTheStartOfBlocks: true
+MacroBlockBegin: ''
+MacroBlockEnd:   ''
+MaxEmptyLinesToKeep: 1
+NamespaceIndentation: All
+ObjCBlockIndentWidth: 4
+PenaltyBreakBeforeFirstCallParameter: 19
+PenaltyBreakComment: 300
+PenaltyBreakFirstLessLess: 120
+PenaltyBreakString: 1000
+
+PenaltyExcessCharacter: 1000000
+PenaltyReturnTypeOnItsOwnLine: 60
+PointerAlignment: false
+SpaceAfterCStyleCast: false
+SpaceBeforeAssignmentOperators: true
+SpaceBeforeParens: Never
+SpaceInEmptyBlock: false
+SpaceInEmptyParentheses: false
+SpacesBeforeTrailingComments: 1
+SpacesInAngles:  false
+SpacesInContainerLiterals: true
+SpacesInCStyleCastParentheses: false
+SpacesInSquareBrackets: false
+
+# Include sorting rules:
+# ".h"
+# ".hpp"
+#
+# <>
+SortIncludes: true
+IncludeBlocks: Regroup
+IncludeCategories: 
+    - Regex: '^".*\.h"'
+      Priority: 1
+      SortPriority: 1
+    - Regex: '^".*\.hpp"'
+      Priority: 1
+      SortPriority: 2
+    - Regex: '^<.*>'
+      Priority: 2
+    - Regex: '.*'
+      Priority: 10
+# Deactivate the main header sorting
+IncludeIsMainRegex: '^A'
+
+# Comments will be formatted similar to the function calls
+ReflowComments: true

.github/PULL_REQUEST_TEMPLATE/common-mistakes.md

@@ -0,0 +1,145 @@
+# List of things to check before submitting the code for review
+
+This document presents the common mistakes often seen during the review and
+also includes some general guidelines in code writing and testing.
+
+Please make sure as a PR (Pull-Request) submitter
+(or as a first-stage code reviewer) these are eliminated wherever possible.
+
+## General
+
+-   Use PR / commit descriptions where possible to indicate what has
+    changed, it helps your peer reviewer to understand basic differences
+    among 20+ commits
+
+-   Don't change the status of the associated Jira ticket(s to implemented unless merged and
+    **agreed with your reviewer**
+
+-   Include ticket number in the Pull-Request message (the PR template will
+    have an entry for you to fill in)
+
+## Builds
+
+-   Don't submit a branch for a review unless it passes all pre-submit CI
+    jobs
+
+-   Check that your code didn't add any new compiler warnings
+
+## Library code
+
+-   Don't reinvent the *wheel*, reuse existing infrastructure
+
+    Chance that you need something slightly different which tempts
+    you to write a very similar function to an existing one is
+    likely an indicator that you should think twice.
+
+-   **Do NOT copy/paste code**. There might be rare occasions where it is
+    useful but in general it denotes bad code design (particularly for
+    bigger code blocks). Consider using a function or a template
+    function with parameters.
+
+-   Calls to functions (e.g., internal ones) should check for their
+    return `status` which is propagated down the call stack in transparent
+    manner (use as appropiate `return error(...);` or `return status;`)
+
+-   Use variable names matching their common interpretation and ideally
+    only in that context
+
+    e.g., `i` ~ row index, `j` ~ column index
+
+-   Use `const` keyword on pointers and references wherever required
+    (including the internal functions) but don't use them for
+    scalars passed-by-value.
+
+    Use `const` also when casting constant pointers (otherwise you might wipe
+    this protection off).
+
+-   Document your code, particularly pay extra attention to
+
+    -   New data structures, enums, etc.
+
+    -   Internal functions with many parameters: is it obvious how all
+        parameters are connected? Will it ever get reused?
+
+-   Test all aspects of your input early in your user-facing API
+
+    -   Never dereference a pointer without checking earlier that it is
+        not `nullptr` (or `NULL`)
+
+## Documentation
+
+-   Build the documentation and read it from there if the formatting is
+    correct
+
+    -   Is the API listed in `.rst` files that the documentation appears
+        at all?
+
+-   Imagine that you read the documentation without prior knowledge of
+    the API, would you be able to use it? Write examples? Understand
+    what needs to be on input and how to process output?
+
+-   Are all errors the API can return listed?
+
+-   Follow the common patterns how to refer to things, examples:
+
+    -   If your API has an example, include it in the documentation via *collapsed
+        file loading*
+
+-   Typography: don't place **spaces** before commas, semicolons,
+    colons etc. (e.g., not *~~word1 , word2 : word3~~* but *word1,
+    word2: word3*)
+
+## Example
+
+-   Check returned status of all public APIs called
+
+-   Include a basic check if the API works and return non-zero code if
+    it didn't, this helps to use the example as a test in the CTest framework
+
+## Testing
+
+-   Good practice is to run only your new unit tests and check the
+    coverage. Do you see what you expected? Ideally coverage LOC percentage would
+    not decrease
+
+-   When creating wrong input cases, make sure that exactly one thing is
+    wrong (e.g., if matrix is supposed to be symmetric and of matching
+    dimensions, there should be multiple test cases such as the
+    dimension is right but it is not symmetric, it is symmetric but the
+    dimension is wrong)
+
+    -   Also make it just slightly wrong, not by miles (e.g., if we
+        expect $n=m$, choosing 5 & 6 might be more likely to fail than 5
+        & 234891)
+
+-   Choose such input that it is likely to detect error, examples what
+    not to do:
+
+    -   square matrix $m=n$ so making a mistake by swapping $n$ & $m$ is not
+        discovered
+
+    -   input vector or matrix of all ones doesn't test that the correct indices are
+        accessed
+
+    -   Complex numbers with same real and imaginary parts
+
+-   Test on edge case input as well as typical
+
+    -   e.g., 0-sizes, 0-nnz, 1 row matrix, ...
+
+-   Set correct tolerances for the expected results, use tolerance relative to machine epsilon
+
+-   Use standardized facilities to check if your results match with the
+    reference, **don't write comparison functions that already exist**
+
+-   If using radnomly generated data, initialize the random seed to allow for
+    reproducibility
+
+-   In positive quick exit tests, check the validity of the output
+    (e.g., that the matrix generated which is supposed to be empty is
+    indeed valid, of the right dimension and empty)
+
+-   It might not be necessary to test a complete combination of all
+    parameters with the same input, although sometimes it might be desirable. It
+    might make more sense to vary the input for different types to get
+    better coverage with smaller number of tests.