Skip to content
New issue

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

Using type_name in .swiftlint.yml causes incorrect style errors #526

Closed
sarambasich opened this issue Feb 11, 2016 · 3 comments
Closed

Using type_name in .swiftlint.yml causes incorrect style errors #526

sarambasich opened this issue Feb 11, 2016 · 3 comments
Labels
bug Unexpected and reproducible misbehavior.

Comments

@sarambasich
Copy link

Abstract

If I try to control how type_name rule (length) behaves in my project, any type that IS legal throws an error when run against the linter.

Steps for reproduction

  1. Open an Xcode project that has some types declared
  2. Add swiftlint
  3. Touch .swiftlint.yml file
  4. Paste the following into the yml file:
disabled_rules: # rule identifiers to exclude from running
  - trailing_whitespace
  - closing_brace
  - variable_name
  - nesting

type_name:
    min_length: 2
    max_length: 40

variable_name:
    min_length: 500
    max_length: 1000

file_length:
    warning: 1000
    error: 1500

Then compile the project with swiftlint enabled

Expected behavior

Any type names less than two characters and greater than forty characters are flagged as a warning.

Actual behavior

Type names that do fit in the 2-40 range are marked as an error:

screen shot 2016-02-11 at 5 09 24 pm
screen shot 2016-02-11 at 5 10 07 pm

Workaround

Remove the rule from the .swiftlint.yml file and no errors are generated.

Attempted resolutions:

  • Tried changing the type_name rule to:
type_name:
    min_length: 2
    max_length:
        warning: 40
        error: 50

This caused swiftlint to ignore the rule altogether.

Version

$ swiftlint version
0.8.0

I am not sure if my yml format is invalid or if something else is going wrong. This was not occurring until I brew upgrade'd today to 0.8.0.

Any help would be greatly appreciated. And thank you for this tool and the help.

@scottrhoyt
Copy link
Contributor

@jpsim do you think this is the same error as #522 ?

@jpsim
Copy link
Collaborator

jpsim commented Feb 11, 2016

Yes, this is the same as #522 which has been fixed on master and will be included in the next release.

Thanks for reporting @ArtisOracle!

@jpsim jpsim closed this as completed Feb 11, 2016
@jpsim jpsim added the bug Unexpected and reproducible misbehavior. label Feb 11, 2016
@sarambasich
Copy link
Author

Thank you!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected and reproducible misbehavior.
Projects
None yet
Development

No branches or pull requests

3 participants