Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: arduino/arduino-lint
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: c6e7e93
Choose a base ref
...
head repository: arduino/arduino-lint
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: ff3b56a
Choose a head ref
  • 7 commits
  • 24 files changed
  • 1 contributor

Commits on Aug 26, 2021

  1. Add and expand rule descriptions

    The `Description` field of the rule configuration was previously only used to add supplemental information to the verbose
    tool output. In this usage, it did not need to stand on its own as a complete documentation of the rule, and also was not
    a high priority since the verbose output is likely not as frequently used.
    
    A new requirement for the rule configuration data has emerged from the project to publish a list of rules. The
    `MessageTemplate` data is not suitable for use in this application due to being written for use in indicating a problem
    that was found, rather than a documentation of the rule. The new requirement is compatible with the existing use of the
    `Description` field, so it is not necessary to add a new field. However, the existing content of the `Description field
    is mostly not inadequate, so it must be expanded.
    
    This content is now written in Markdown. Its existing use is limited to the JSON format output. Since the Markdown syntax
    is very lightweight and intuitive, and any reader of the JSON format output will already have been presented with plenty
    of syntax, I don't think the change has a harmful effect on that output.
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    d126e70 View commit details
    Browse the repository at this point in the history
  2. Add test for empty required rule configuration fields

    The tool output and rules list assume that the text in the required rule configuration fields is present. In cases where
    it is left empty, this assumption might result in strange or misformatted output. At the moment they are all populated,
    so that assumption is fine. In the event the test catches an empty field, it can either be fixed or the code changed to
    not rely on that field being populated.
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    8aca928 View commit details
    Browse the repository at this point in the history
  3. Publish generated list of rules on documentation website

    This will provide a convenient reference for information about the rules Arduino Lint applies to projects.
    
    - More verbose description of the rule than would be appropriate for the command line output.
    - Link to the reference information that will allow the reader to fully understand the cause of the rule violation and
      how to fix it.
    - Table showing the rule violation level (i.e., error/warning/disabled) vs. common tool configuration.
    
    I added a bespoke "Rules > Introduction" page to give some general information about the rule system. , but the "Sketch",
    "Library", "Platform", and "Package index" pages are all auto-generated from the Arduino Lint source code and will be
    automatically updated any time rules are added or modified without any additional effort.
    
    The rule documentation content is generated by the "ruledocsgen" Go program, which is a separate module, located in its
    own subfolder of the repository, similar to the standardized "docsgen" program that generates the command line reference.
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    13d8760 View commit details
    Browse the repository at this point in the history
  4. Use different syntax style for arbitrary array elements in rule descr…

    …iptions
    
    Some of the rules must refer to data paths in configuration files such as the package index. In the case of arrays, it is
    necessary to indicate that the reference applies to an arbitrary element. Prefiously, the `[]` syntax was used for this
    purpose (e.g., `packages[].tools[]`). It is now changed to using `[*]` (e.g., `packages[*].tools[*]`).
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    5fc2ed4 View commit details
    Browse the repository at this point in the history
  5. Escape Markdown markup in rule reference Brief text

    The primary purpose of text of the rule configuration's `Description` field is for display in the rule reference section
    of the documentation website. For this reason, it is written in Markdown, and thus can be output as is.
    
    The situation is different with the rule configuration's `Brief` field, since it is displayed prominently in the tool
    output. For this reason, the use of Markdown would not be appropriate. This text may contain incidental markup characters
    that would result in unwanted formatting and thus the `Brief` field text must be escaped for display on the website.
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    f62a372 View commit details
    Browse the repository at this point in the history
  6. Refer to the platform "extra_flags" properties in a less confusing ma…

    …nner
    
    There is a convention of configuring Arduino boards platforms to provide a user interface for configuring the build
    process through the addition of references and fallback empty definitions of a series of properties that follow the
    format of `compiler.<pattern type>.extra_flags`, where "<pattern type>" corresponds to the compilation pattern that
    references them:
    
    - `c`
    - `cpp`
    - `S`
    - `ar`
    - `c.elf`
    
    Previously, `x` was used as a placeholder for the component of the property name that varies in order to allow a single
    rule to refer to the entire set. "<pattern type>" is a little bit more clear than "x".
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    fbda05e View commit details
    Browse the repository at this point in the history
  7. Use a different term when referring to additional data properties in …

    …rule messages
    
    Feedback was provided that the previous "additional" term was not very clear. "Unrecognized" was determined to be better.
    per1234 committed Aug 26, 2021
    Configuration menu
    Copy the full SHA
    ff3b56a View commit details
    Browse the repository at this point in the history
Loading