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

Putting `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0 breaks `attributes` rule #2141

Closed
JakeLin opened this Issue Apr 4, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@JakeLin

JakeLin commented Apr 4, 2018

New Issue Checklist

Bug Report

Complete output when running SwiftLint, including the stack trace and command used
$ swiftlint lint
./Pods/SwiftLint/swiftlint lint --path /Users/jake/dev/WhateverTests.swift  --no-cache --enable-all-rules
Linting Swift files at path /Users/jake/dev/WhateverTests.swift
Linting 'WhateverTests.swift' (1/1)
/Users/jake/dev/WhateverTests.swift:7:9: warning: Attributes Violation: Attributes should be on their own lines in functions and types, but on the same line as variables and imports. (attributes)
Done linting! Found 1 violations, 0 serious in 1 file.

Environment

  • SwiftLint version (run swiftlint version to be sure)? - 0.25.0
  • Installation method used (Homebrew, CocoaPods, building from source, etc)? - CocoaPods
  • Paste your configuration file:
whitelist_rules:
  - attributes
  - block_based_kvo
  - class_delegate_protocol
  - closing_brace
  - closure_end_indentation
  - closure_parameter_position
  - closure_spacing
  - comma
  - compiler_protocol_init
  - control_statement
  - custom_rules
  - discouraged_direct_init
  - dynamic_inline
  - empty_count
  - empty_enum_arguments
  - empty_parameters
  - empty_parentheses_with_trailing_closure
  - explicit_init
  - extension_access_modifier
  - fatal_error_message
  - first_where
  - for_where
  - force_try
  - generic_type_name
  - implicit_getter
  - is_disjoint
  - joined_default_parameter
  - large_tuple
  - leading_whitespace
  - legacy_cggeometry_functions
  - legacy_constant
  - legacy_constructor
  - legacy_nsgeometry_functions
  - let_var_whitespace
  - mark
  - multiple_closures_with_trailing_closure
  - nesting
  - opening_brace
  - operator_usage_whitespace
  - operator_whitespace
  - overridden_super_call
  - pattern_matching_keywords
  - private_outlet
  - private_over_fileprivate
  - private_unit_test
  - prohibited_super_call
  - protocol_property_accessors_order
  - redundant_discardable_let
  - redundant_nil_coalesing
  - redundant_optional_initialization
  - redundant_string_enum_value
  - redundant_void_return
  - return_arrow_whitespace
  - shorthand_operator
  - single_test_class
  - statement_position
  - syntactic_sugar
  - todo
  - trailing_comma
  - trailing_newline
  - trailing_semicolon
  - trailing_whitespace
  - unneeded_parentheses_in_closure_argument
  - unused_closure_parameter
  - unused_enumerated
  - unused_optional_binding
  - valid_ibinspectable
  - vertical_whitespace
  - void_return

disabled_rules:
  # Not going to turn this on until this is resolved https://github.com/realm/SwiftLint/issues/637
  # - colon
  # Too irritating
  # - conditional_returns_on_newline
  # Too irritating
  # - cyclomatic_complexity
  # No longer need as iOS 10 automatically dispose observer
  # - discarded_notification_center_observer
  # Too irritating
  # - explicit_enum_raw_value
  # We are not building library for others, no need for our app
  # - explicit_top_level_acl
  # Too irritating
  # - explicit_type_interface
  # Don't care
  # - file_header
  # Ideally, but no
  # - file_length
  # Too irritating
  # - force_cast
  # Too irritating
  # - force_unwrapping
  # Not really practical
  # - function_body_length
  # Not so useful
  # - function_parameter_count
  # Not so useful
  # - identifier_name
  # There are valid use cases
  # - implicitly_unwrapped_optional
  # Doesn't make things more readable
  # - implicit_return
  # Not really practical
  # - line_length
  # Not really practical
  # - multiline_parameters
  # Not useful
  # - no_extension_access_modifier
  # Not making test any easier to read
  # - nimble_operator
  # Not useful
  # - no_grouping_extension
  # Not useful
  # - notification_center_detachment
  # Not useful
  # - number_separator
  # Not useful
  # - object_literal
  # Not really practical
  # - quick_discouraged_call
  # Don't bother until Xcode supporting sorting automatically
  # - sorted_imports
  # Not really practical
  # - strict_fileprivate
  # I like it that way
  # - switch_case_on_newline
  # Not really practical
  # - trailing_closure
  # Not really practical
  # - type_body_length
  # Don't care
  # - type_name
  # Don't care
  # - vertical_parameter_alignment
  # Don't care
  # - vertical_parameter_alignment_on_call
  # Don't care
  # - xctfail_message
  # Not really practical
  # - weak_delegate

custom_rules:
  no_hard_coded_strings:
    included: "/WhateverApp/.+/(Controller|View|ViewModel)/.+swift"
    regex: "([A-Za-z]+)"
    match_kinds: string
    message: "Hard-coded string is never a good practice ☠️"
    severity: warning

  no_f:
    included: ".+Tests.swift"
    regex: "(fit|fdescribe|fcontext)"
    match_kinds: identifier
    message: "Please kindly remove the `f..()` test 🚫"
    severity: warning
  • Are you using nested configurations?
    If so, paste their relative paths and respective contents. - No
  • Which Xcode version are you using (check xcode-select -p)? Version 9.3 (9E145)
  • Do you have a sample that shows the issue? Run echo "[string here]" | swiftlint lint --no-cache --use-stdin --enable-all-rules
    to quickly test if your example is really demonstrating the issue. If your example is more
    complex, you can use swiftlint lint --path [file here] --no-cache --enable-all-rules. -- See the Complete output above please
// This triggers a violation:
private struct DefaultError: Error {}

To fix it we need to put an enter like

private 
struct DefaultError: Error {}

Thanks for looking at it, please advise if I have done something wrong.

@JakeLin JakeLin changed the title from Can put `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0, break `Attributes Violation: Attributes should be on their own lines in functions and types, but on the same line as variables and imports. (attributes)` to Can NOT put `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0, break `Attributes Violation: Attributes should be on their own lines in functions and types, but on the same line as variables and imports. (attributes)` Apr 4, 2018

@JakeLin JakeLin changed the title from Can NOT put `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0, break `Attributes Violation: Attributes should be on their own lines in functions and types, but on the same line as variables and imports. (attributes)` to Can NOT put `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0, break `attributes` rule Apr 4, 2018

@JakeLin JakeLin changed the title from Can NOT put `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0, break `attributes` rule to Putting `private` and `struct` on the same line for Version 9.3 (9E145) and SwiftLint 0.25.0 breaks `attributes` rule Apr 4, 2018

@marcelofabri

This comment has been minimized.

Collaborator

marcelofabri commented Apr 5, 2018

Potentially related to #2125.

@marcelofabri marcelofabri added the bug label Apr 5, 2018

@JakeLin

This comment has been minimized.

JakeLin commented Apr 5, 2018

@marcelofabri I think so, but the title of #2125 seems wrong.

@marcelofabri

This comment has been minimized.

Collaborator

marcelofabri commented Apr 5, 2018

I think both issues are instances of a broader problem (we should keep both issues for now).

@marcelofabri

This comment has been minimized.

Collaborator

marcelofabri commented Apr 7, 2018

Fixed in #2148

@JakeLin

This comment has been minimized.

JakeLin commented Apr 9, 2018

@marcelofabri thank you very much, it's working now.

@marcelofabri

This comment has been minimized.

Collaborator

marcelofabri commented Apr 9, 2018

@JakeLin thanks for confirming 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment