sonar assignment of parameter is not allowed

SonarQube Properties and Parameters

Parameters to configure project analysis can be set in multiple places. Here is the hierarchy of parameters:

• Global analysis parameters, defined in the UI, apply to all the projects (From the top bar, go to Settings > General Settings)
• Project analysis parameters, defined in the UI, override global parameters (At a project level, go to Configuration > Settings)
• Project analysis parameters, defined in a project analysis configuration file or an analyzer configuration file, override the ones defined in the UI
• Analysis / Command line parameters, defined when launching an analysis, override project analysis parameters

For example, if you override the sonar.exclusions parameter via command line for a specific project, it will not be stored in the database. Local analyses in Eclipse, for example, would still be executed with the exclusions defined in the UI and therefore stored in the DB.

Setting properties from the Command Line

SonarQube properties can also be set from the command line, by setting a system property named exactly like the SonarQube property in question. This can be useful when dealing with sensitive information (e.g. credentials), environment information, or for ad-hoc configuration.

A SonarQube property value set via a system property overrides any value set in a build script (for the same property). When analyzing a project hierarchy, values set via system properties apply to the root project of the analyzed hierarchy. Each system property starting with ""sonar." will be taken into account.

sonar-project.properties

Create a configuration file in the root directory of the project: sonar -project.properties

Alternatives to  sonar-project.properties

If a  sonar-project.properties  file cannot be created in the root directory of the project, there are several alternatives:

The properties can be specified directly through the command line. Ex:

The property project.settings can be used to specify the path to the project configuration file (this option is incompatible with the project.home and sonar.projectBaseDir properties). Ex:

Alternate Analysis Directory

If the files to be analyzed are not in the directory where the analysis starts from, use the sonar.projectBaseDir property to move analysis to a different directory. E.G. analysis begins from  jenkins/jobs/myjob/workspace  but the files to be analyzed are in  ftpdrop/cobol/project1 .

Multi-module Project Structure

If your project is a Maven project, you have nothing further to do to enable multi-module analysis. Simply execute mvn sonar:sonar from your project's root directory. If your multi-module project is not a Maven project, read on:

There are two ways to define a multi-module structure in SonarQube:

Gradle defaults for standard SonarQube properties

Mandatory Parameters

Project Configuration

Optional Parameters

Project identity.

Authentication

If Anyone does not have permission to perform analyses, you'll need to supply the credentials of a user with Execute Analysis permission for the analysis to run under.

Web Services

Exclusions / Inclusions

See Narrowing the Focus to:

• Exclude files from analysis
• Prevent some files from being checked for duplications
• Prevent some files from being taken into account for code coverage by unit tests and integration tests
• Ignore issues on certain components and against certain coding rules 

Duplications

Analysis Logging

Parameters specific to Integration

Those parameters are listed here for completeness of this documentation page - but regular users should not have to worry about them because they mainly target integration use cases.

https://docs.sonarqube.org/display/SCAN/Advanced+SonarQube+Scanner+Usage https://docs.sonarqube.org/display/SONAR/Analysis+Parameters

  Call us on +91 700 483 5930   |   +91 700 483 5706     [email protected]

Is it possible to get some customized parameters in Custom rule?

Following This tutorial , I can write my custom rule checker.

For now, I can only get the key of project via context.getProject().key() .

The key is defined from scanner command line such as -Dsonar.projectKey=keyOfProject

Is It possible I can defined more customized parameters in the same way and received them in my custom rule?

If not, May be this is a new useful API worthy of implementation?

What’s the ultimate goal – how would you use this when developing rules?

Most customised parameters would be defined for the rule and then adjusted as part of a Quality Profile.

In my case, I want to pass an unique ID to the rule, although the rule is already defined in a specific Quality Profile. But I need this unique ID for applying different checks in the same rule.

Is is possible for me to do that?

In this case, we’d probably suggest creating different rules (the behavior of how the check is applied should be defined mostly by what rules are active in a quality profile, not by analysis parameter).

There are some exceptions you could try and model after if you’re really certain this makes sense, like how we adjust rules based on the sonar.java.version analysis parameter.

Thanks Colin. That helps a lot.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Kotlin] Bogus errors NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR #1036

rupert-jung-mw commented Aug 29, 2024 • edited Loading

The text was updated successfully, but these errors were encountered:

gtoison commented Aug 29, 2024

Sorry, something went wrong.

• 👍 1 reaction

rupert-jung-mw commented Aug 29, 2024

rupert-jung-mw commented Aug 30, 2024 • edited Loading

No branches or pull requests

Alexis Ada Reference Manual

• Legal Information
• Contact Alexis

• warning: Undefined array key "value" in /home/clients/www/drupal/sites/all/modules/fivestar/fivestar.module on line 1121.
• warning: Undefined array key "value" in /home/clients/www/drupal/sites/all/modules/fivestar/fivestar.module on line 1136.
• warning: Undefined array key "value" in /home/clients/www/drupal/sites/all/modules/fivestar/fivestar.module on line 1137.

assignment to "in" mode parameter not allowed

You cannot assign a read-only variable.

When you learn about Ada, you are taught that parameters are passed as copy when you are using the in keyword. The fact is that the compiler can decide to pass the parameter by reference and therefore it views the variable as a read-only variable. You cannot write in that variable.

For instance, a loop through a linked list to find the last element in the list could look like this:

The solution to the problem is to create a local instance and copy the read-only variable in the local instance variable.

• Login to post comments
• GNAT Errors
• Compiler Results

Latest Edits

• 3.6 Array Types
• 3.5.5 Operations of Discrete Types
• 3.5.9 Fixed Point Types
• Section 7: Packages
• Introduction

External References

• Annotated Ada 2005 Reference Manual
• ACATS 3.0 User's Guide
• Ada 2005 Tests
• Annotated Ada 2012 Reference Manual
• Ada 95 Reference Manual

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

"Optional parameters should not be used" error thrown in SonarQube analysis

I'm getting error - "Optional parameters should not be used" in Sonar analysis for C# project. Actually in C# latest version we can define optional parameter but SonarQube analysis says Optional parameters should not be used. How can I solve this issue? I'm using latest SonarQube version 6.0.

• optional-parameters

• 1 Your question is like this : I getting some error, It is because of some x ; how can i solve that? Definitely their may be someone ready to help you, please be clear about your issues help him to understand the issues –  sujith karivelil Commented Jan 3, 2017 at 6:00

You can either deactivate the rule on your SonarQube server or mark it as False Positive for your particular case but I would recommend you to have a look at why we created this rule before you deactivate it. You can find more information about this rule on our Rules website or on Microsoft website .

• Rules website link mentioned in your reply is not working. –  Rasik Bapotra Commented Jan 13, 2017 at 10:36
• Hi Rasik, I just checked and both links are working from here (Switzerland). Could you check it is not your firewall? –  Amaury Levé Commented Jan 13, 2017 at 13:09
• I'm still not able to open it. Can you please send it to [email protected] . –  Rasik Bapotra Commented Jan 19, 2017 at 8:17
• Not sure if this will change something but I did it. –  Amaury Levé Commented Jan 19, 2017 at 10:56

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged c# sonarqube optional-parameters or ask your own question .

• The Overflow Blog
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...
• Staging Ground Reviewer Motivation

Hot Network Questions

• Representing permutation groups as equivalence relations
• What prevents random software installation popups from mis-interpreting our consents
• Show that an operator is not compact.
• Star Trek: The Next Generation episode that talks about life and death
• Where is this railroad track as seen in Rocky II during the training montage?
• Why is this bolt's thread the way it is?
• In a tabular with p-column, line spacing after multi-line cell too short with the array package
• How to automatically assign Material in slot to generated mesh from Geometry Node
• Calculating greeks by finite difference in MC simulation
• Numbers, or are they?
• Intersection of Frobenius subalgebra objects
• help to grep a string from a site
• How does the phrase "a longe" meaning "from far away" make sense syntactically? Shouldn't it be "a longo"?
• Gravitational potential energy of a water column
• Why didn't Air Force Ones have camouflage?
• What is the nature of the relationship between language and thought?
• Current in a circuit is 50% lower than predicted by Kirchhoff's law
• Why is LiCl a hypovalent covalent molecule?
• How to change upward facing track lights 26 feet above living room?
• How can we know how good a TRNG is?
• Does the average income in the US drop by $9,500 if you exclude the ten richest Americans?
• Is there a way to prove ownership of church land?
• Children in a field trapped under a transparent dome who interact with a strange machine inside their car
• Should Euler be credited with Prime Number Theorem?

Analysis scope

On this page.

There are many cases where you do not want to analyze every aspect of every source file in your project. For example, your project may contain generated code, source code from libraries, or intentionally duplicated code.

In such cases, it makes sense to skip some or all aspects of analysis for these files, thus removing noise and narrowing the focus to issues that really matter.

To help narrow the focus, SonarQube gives you several options to precisely configure what will be analyzed and how. Most of the properties that define your analysis scope can be defined in the SonarQube UI. Other parameters must be set explicitly in the scanner invocation or in the appropriate configuration file as we describe in more detail below; see the Analysis parameters page for more detail.

.css-4ebt6d{position:relative;--tw-text-opacity:1;color:rgb(0 0 0 / var(--tw-text-opacity));} Setting the initial scope .css-abpesc{width:2rem;display:none;margin-left:0.5rem;fill:#5F656D;}.css-abpesc:hover{fill:#290042;}

The initial scope of analysis is controlled by the following parameters:

• sonar.sources  define the initial scope of analysis for non-test code in your project.
• sonar.tests  define the initial scope of analysis for test code in your project.

These parameters define the starting point for analysis scope adjustment:

• Files outside the scope defined by these parameters  will not  be analyzed at all.
• Files within the scope defined by these parameters  will  be analyzed  unless excluded by further adjustments  (exclusions, inclusions, etc. See below.)

Additionally, these parameters are:

• only set at the project level. There are no global, server-level equivalents for these parameters.
• either set automatically by your SonarScanner, set explicitly in the  sonar-project.properties  configuration file, or set on the command line that invokes the scanner. There are no UI settings for these parameters.
• set explicitly and both accept a comma-delimited list of paths. Pattern matching with wildcards is not supported.

Why is test code scoped separately? .css-p7dib0{width:1.75rem;display:none;margin-left:0.5rem;fill:#5F656D;}.css-p7dib0:hover{fill:#290042;}

Test and non-test code are distinguished because

• Different analysis rules are applied to the two categories.
• The two categories have different metrics
• Test code does not count toward lines-of-code limits defined by your license.
• Test code does not count towards coverage (you don't have to test your test code)

Automatic setting for Maven, Gradle, and .NET

If you are analyzing code using SonarScanner for Maven, SonarScanner for Gradle, or SonarScanner for .NET, the  sonar.sources  and  sonar.tests  parameters are automatically determined based on information in your project configuration. You do not have to explicitly set the parameters. If you do explicitly set the parameters (for example in your  pom.xml , in the case of Maven), this will override the automatically determined values.

If you use SonarScanner for Maven, see also Adjusting the analysis scope of Maven projects .

Defaults settings for other scenarios

If you are not using Maven, Gradle or .NET then

• By default,  sonar.sources  is set to the current working directory (the path  . ).
• By default,  sonar.tests  is not set.

Explicit settings

If the defaults are not suitable (for example, if you  do  have test code) you must set the parameters explicitly in the scanner invocation or in the appropriate configuration file (see Analysis parameters ).

When explicitly set, both  sonar.sources  and  sonar.tests  take a comma-delimited list of directories or files.

• The entries in the list are simple paths. Wildcards ( * ,  ** , and  ? ) are not allowed.
• A directory in the list means that all analyzable files and directories recursively below it are included. An individual file in the list means that the file is included.
• The paths are interpreted relative to the project base directory. The base directory is defined by the scanner you are using. In most cases, this is the root directory of the project. If you are using the SonarScanner CLI, your base directory will be the current directory from which you invoke the tool (though this can be overridden using the parameter  sonar.projectBaseDir ).

Let's say your repository looks something like this, with your source and test code clearly separated at the top level:

In this case, you would set your  sonar.sources  like this:

and your  sonar.tests  like this:

If you configure your scope in the  sonar-project.properties  file, it would look like this:

There is no need for any further fine-tuning.

Wildcard patterns

While the  sonar.sources  and  sonar.tests  parameters take simple paths, most of the parameters discussed below use path-matching patterns.

The recognized path-matching patterns are defined using the following wildcards:

• *  Match zero or more characters (not including the directory delimiter,  / ).
• **  Match zero or more directory segments within the path.
• ?  Match a single character (not including the directory delimiter,  / ).

Wildcard examples

• matches  anyDirectory/anyFile.css
• doesn't match  org/sonar.api/MyBean.java
• matches  org/sonar.api/MyBean.java
• doesn't match  org/sonar/util/MyDTO.java
• matches  org/sonar/util/MyOtherBean1.java
• doesn't match  org/sonar/util/MyOtherBean.java
• matches  org/sonar/MyClass.java
• doesn't match  org/sonar/util/MyClassUtil.java
• matches  org/sonar/anyDirectory/anyFile
• matches org/sonar/MyClass.java
• doesn't match  org/radar/MyClass.java

Location of UI settings

Unless otherwise noted, all the parameters below are settable at both the global and project level. The UI locations for the settings are found under:

• Administration > Configuration > General Settings (for global settings)
• Project Settings > General Settings (for project-level settings)

Any setting made at the global level will apply to all projects unless overridden at the project level (the only exceptions are the global exclusion parameters discussed above).

File exclusion and inclusion

If the directory structure of your project does not cleanly separate source code from test code at the top level, you may have to adjust the scope using exclusions and inclusions.

Inclusions and exclusions should not be part of the initial analysis configuration. We recommend setting them only to solve issues. For example, when you notice that an analysis picked up files that you did not want analyzed.

These are set in the UI for both global and project levels, as follows:

Global level

Administration > Configuration > General Settings >  Analysis Scope > A. File Exclusions

• Global Source File Exclusions : One or more wildcard patterns defining which files are filtered out from those defined by  sonar.sources . This setting will apply to all projects on your SonarQube server. It cannot be overridden by any project-level source file exclusion. It also cannot be set as a key in a configuration file. If it is set, it must be set in the UI.
• Source File Exclusions : The same as the global version above except that it  can  be overridden by a project-level source file exclusion. It cannot be set as a key in a configuration file. If it is set, it must be set in the UI.
• Global Test File Exclusions : Same as the Global Source File Exclusions, above, except that it applies to test files.
• Source File Inclusions : One or more wildcard patterns defining which files to retain, while filtering out all others, from those defined by  sonar.sources . This applies to all projects on your SonarQube server, though it can be overridden at the project level. It cannot be set as a key in a configuration file. If it is set, it must be set in the UI.
• Test File Exclusions : Same as the Source File Exclusions, above, except that it applies to test files.
• Test File Inclusions : Same as the Source File Inclusions, above, except that it applies to test files.

Project level

Project Settings > General Settings >  Analysis Scope > A. File Exclusions

• Source File Exclusions : One or more wildcard patterns defining which files are filtered out from those defined by  sonar.sources . This can also be set in a configuration file using the key  sonar.exclusions .
• Source File Inclusions : One or more wildcard patterns defining which files to retain, while filtering out all others, from those defined by  sonar.sources . This can also be set in a configuration file using the key  sonar.inclusions .
• Test File Exclusions : One or more wildcard patterns defining which files are filtered out from those defined by  sonar.tests . This can also be set in a configuration file with the key  sonar.test.exclusions .
• Test File Inclusions : One or more wildcard patterns defining which files to retain, while filtering out all others, from those defined by  sonar.tests . This can also be set in a configuration file using the key  sonar.test.inclusions .

To set these parameters by key you can:

• Set them in the configuration file  <YOUR_PROJECT>/sonar-project.properties .
• Set them on the command line when invoking the scanner.
• In the case of Maven, Gradle, or .NET projects, set them in the appropriate framework-specific configuration file.

How the parameter values are interpreted

The wildcard patterns are interpreted relative to the project base directory.

Exclusions and inclusions apply  on top of  the  sonar.sources  and  sonar.tests  settings. Both the exclusion and inclusion parameters act as filters. They only ever reduce the number of files in the analyzable set, they never add to the set.

Let's say your repository looks something like this, with your test code intermingled with your source code:

You would define your  sonar.sources  like this, taking in the whole  src  directory:

and then set  Source File Exclusions  (key  sonar.exclusions ) to

The result is that the set of source files to be scanned is everything under  src  minus every  test  subdirectory:

To define the test files, first set  sonar.tests  to the whole  src  directory:

and then set  Test File Inclusions  (key  sonar.test.inclusions ) to

The result is that the set of source files to be scanned is everything under  src   minus everything that is not  a  test  subdirectory:

Naming of parameters

Note that the initial scoping parameter for test code is  sonar.tests  (that's  tests  with an  s !) while the exclusion and inclusion parameters for test code are  sonar.test.exclusions  and  sonar.test.inclusions  (that's  test , without an  s !).

Relationship with test coverage reporting

The test scoping parameters (  sonar.tests ,  sonar.test.exclusion , and  sonar.test.inclusion ) do not have anything to do with setting up test coverage reporting (see  Test coverage ). However, SonarQube will report an error if an imported coverage report lists a test file not encountered in the directories specified by the scoping parameters.

The parameter  sonar.coverage.exclusions , on the other hand, is directly related to test coverage reporting (see below).

Code coverage exclusion

Analysis Scope > B. Code Coverage Exclusions

This setting lets you exclude specific files or directories from code coverage reporting. The value of the parameter is a comma-delimited list of path-matching patterns relative to the current working directory.

When setting by key, use  sonar.coverage.exclusions

Duplication exclusions

Analysis Scope > C. Duplication Exclusions

This setting lets you exclude specific files or directories from duplication checking. The value is a comma-delimited list of path-matching patterns relative to the current working directory.

When setting by key, use  sonar.cpd.exclusions

Setting the scope by file type

Languages >  Your Language

Most languages offer a way to restrict the scope of analysis to files matching a set of extensions. You can specify one or more suffixes (file extensions) for each language. For example, for the C language,  .c  and  .h  are set by default.

When setting by key, use the appropriate parameter of the form  sonar.<LANGUAGE>.file.suffixes .

Setting the secret detection scope

By default, SonarQube detects exposed secrets in all files processed by the language analyzers. You can refine the scope of the secret detection: see Adjusting the secret detection scope .

Ignoring issues in files based on content

Analysis Scope > D. Issue Exclusions > Ignore Issues on Files

You can ignore files that contain a block of code matching a given regular expression. All issues as well as security hotspots, will be ignored within those files. In this setting, you can enter one or more regular expression patterns. Any file containing at least one of the specified patterns will be ignored.

For example, let's say you have generated class files in your Java project that you wish to exclude. The files look something like this:

To exclude all such files, you might set this parameter to:

Note that since this value is a regular expression, you need to escape the  (  and  )  parentheses characters and use the expression  .*  match the string in between those parentheses.

The key for this parameter is  sonar.issue.ignore.allfile , however, because it is a multi-value property, we recommend that it only be set through the UI.

Ignoring blocks within files

Analysis Scope > D. Issue Exclusions > Ignore Issues on Blocks

You can ignore specific blocks of code within a file while continuing to scan the remainder of the file. Blocks to be ignored are delimited within the file by start and end strings. You specify these start and end strings by regular expressions. All issues as well as security hotspots within those blocks, will be ignored. You can enter one or more pairs of regular expression patterns. Any code in any file that lies between the start pattern and its corresponding end pattern will be ignored. Note that:

• If the first regular expression is found but not the second one, the end of the file is considered to be the end of the block.
• Regular expressions are not matched across multiple lines.

For example, let's say you want to ignore the code in the method  doSomethingElse  using block delimiters, like this:

You could specify the following regular expressions:

Start of block :  \s*//\s*START-NOSCAN

End of block:  \s*//\s*END-NOSCAN

These regular expressions ensure that the start and end block delimiters will be recognized regardless of the number of spaces around the line comment characters ( // ).

The key for this parameter is  sonar.issue.ignore.block . However, because it is a multi-value property, we recommend that it only be set through the UI.

Excluding specific rules from specific files

Analysis Scope > D. Issue Exclusions > Ignore Issues on Multiple Criteria

You can prevent specific rules from being applied to specific files by combining one or more pairs of strings consisting of a rule key pattern   and a file path pattern .

The key for this parameter is  sonar.issue.ignore.multicriteria, however, because it is a multi-value property, we recommend that only be set through the UI.

Rule key pattern

A rule key pattern consists of a rule repository name, followed by a colon, followed by a rule key, or a rule name globbing pattern.

For example:

• java:S1195  matches exactly the  rule S1195  in the Java rule repository.
• java:*Naming*  matches all rules in the Java repository that include the string  Naming  in their rule name.

You can find the fully qualified rule ID of the rule definition and the rule name in the rule definition.

For example, for  this rule :

• Rule ID:  css:S4655
• Rule name:  "!important" should not be used on "keyframes"

File path pattern

A file path pattern uses the path-matching format described above to specify a set of directories or files.

File path pattern examples

• Rule key pattern:  *
• File path pattern:  **/*
• File path pattern:  bank/ZTR00021.cbl
• File path pattern:  com/foo/*
• Rule key pattern:  cpp:Union
• File path pattern:  object/**/*

Applying specific rules to specific files

You can only apply specific rules to specific files.

• Global level:  Administration > Configuration > General Settings > Analysis Scope > D. Issue Exclusions > Restrict Scope of Coding Rules
• Project level:  Project Settings > General Settings > Analysis Scope > D. Issue Exclusions > Restrict Scope of Coding Rules

The mechanics of setting these parameters are the same as for  sonar.issue.ignore.multicriteria , above: Each entry consists of a rule key pattern and a file path pattern. The difference is that in this case, it means that the specified rule will only be applied to the specified set of files.

The key for this parameter is  sonar.issue.enforce.multicriteria . However, because it is a multi-value property, we recommend that it should only be set through the UI.

Multi-value pattern examples

• Rule key pattern:  checkstyle:com.puppycrawl.tools.checkstyle.checks.coding.MagicNumberCheck
• File path pattern:  **/*Bean.java
• Rule key pattern 1:  cobol:COBOL.GotoTransferControlOutsideCurrentModuleCheck
• File path pattern 1:  bank/creditcard/**/*
• Rule key pattern 2:  cobol:COBOL.GotoTransferControlOutsideCurrentModuleCheck
• File path pattern 2:  bank/bankcard/**/*

SonarQube respects ignored files

Your SonarQube analysis will automatically exclude files that are ignored by your source code control system. For example, in git repositories, it respects the  .gitignore  file. SonarQube also respects the ignore directives used in SVN repositories.

This behavior can be disabled by setting sonar.scm.exclusions.disabled = true in the configuration file or command line.

Note that while SonarQube understands standard  .gitignore  directives, it does not understand  .gitignore   negation patterns . These are the patterns preceded by an exclamation mark( ! ). We recommend not using them in SonarQube projects.

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.