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.

Sign up for GitHub

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

Jump to bottom

Unable to specify what rules to validate against #1

Closed
aarondaub opened this issue May 18, 2015 · 4 comments
Closed

Unable to specify what rules to validate against #1

aarondaub opened this issue May 18, 2015 · 4 comments

Comments

@aarondaub
Copy link

We should be able to specify what to use - or perhaps specify what rules NOT to use. We should also probably be able to get a list of current rules.
@aarondaub
Copy link
Author

I'll open a PR for this when I'm back at my laptop this evening.

@jpsim jpsim mentioned this issue May 18, 2015
Closed
@jpsim
Copy link
Collaborator

jpsim commented May 18, 2015

That would be great! The design I'm considering is to have a .swiftlint.yml file or similar (I've opened up #2 to track that).

I'd also like a syntax like

// swiftlint:disable_rule:line_length
... some long line
// swiftlint:enable_rule:line_length

I've opened up #4 to track that. PRs are definitely welcome, or even discussion around the design.

@aarondaub aarondaub mentioned this issue May 18, 2015
Closed
@aarondaub
Copy link
Author

I'm having an issue constraining objects to Rule because it has a type alias. Trying to think of a good solution.

This was referenced May 19, 2015
Closed
Closed
@jpsim jpsim mentioned this issue Jul 6, 2015
Closed
@eneko
Copy link

eneko commented Aug 20, 2015

I support the idea of a .swiftlint.yml configuration file to disable or configure some rules, like line_length. Any work completed on that yet?

In addition, I'd like to suggest for the same configuration file to include options to specify which project folders to include or exclude. This will allow for easy excluding of Pods or third party libraries that developers shouldn't be concerned about (unless working on those projects).

jpsim added a commit that referenced this issue Aug 24, 2015
@jpsim
Configure SwiftLint via a YAML file. Fixes #1 and #3.
551a57f
@jpsim jpsim mentioned this issue Aug 24, 2015
Merged
jpsim added a commit that referenced this issue Aug 24, 2015
@jpsim
Configure SwiftLint via a YAML file. Fixes #1 and #3.
f2f1136
jpsim added a commit that referenced this issue Aug 25, 2015
@jpsim
Configure SwiftLint via a YAML file. Fixes #1 and #3.
e31daf0
@jpsim jpsim closed this as completed in 19cc87a Aug 28, 2015
jpsim pushed a commit that referenced this issue Apr 11, 2017
@sammy-SC
Merge pull request #1 from SDGGiesbrecht/trailing-comma-autocorrect
e70af82 
Simplified Offset Processing
@gorbat-o gorbat-o mentioned this issue Jan 23, 2018
Closed
jpsim added a commit that referenced this issue Jan 17, 2023
@jpsim
[CI] Remove 'TSan Runs' job
2035912 
This frequently crashes and I don't think it's due to a real TSan race.

E.g. https://buildkite.com/swiftlint/swiftlint/builds/4912#0185c098-a803-4525-8df1-827d1c97ed01

```
swiftlint(373,0x1ecdd3a80) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
Linting Swift files in current working directory
1 of 538 [                              ] ETA: 0s (13129 files/s)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
ThreadSanitizer:DEADLYSIGNAL
==373==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000102cbe380 bp 0x00016f50ee00 sp 0x00016f50edc0 T30753687)
==373==The signal is caused by a UNKNOWN memory access.
==373==Hint: address points to the zero page.
    #0 __tsan::ThreadClock::release(__tsan::DenseSlabAllocCache*, __tsan::SyncClock*) <null>:46801128 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x2a380)
    #1 __tsan::Release(__tsan::ThreadState*, unsigned long, unsigned long) <null>:46801128 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x7456c)
    #2 swift::runJobInEstablishedExecutorContext(swift::Job*) <null>:46801128 (libswift_Concurrency.dylib:arm64e+0x40588)
    #3 swift_job_runImpl(swift::Job*, swift::ExecutorRef) <null>:46801128 (libswift_Concurrency.dylib:arm64e+0x41404)
    #4 _dispatch_root_queue_drain <null>:46801128 (libdispatch.dylib:arm64e+0x15f90)
    #5 _dispatch_worker_thread2 <null>:46801128 (libdispatch.dylib:arm64e+0x167bc)
    #6 _pthread_wqthread <null>:46801128 (libsystem_pthread.dylib:arm64e+0x30c0)
    #7 start_wqthread <null>:46801128 (libsystem_pthread.dylib:arm64e+0x1e1c)

==373==Register values:
 x[0] = 0x0000000102a53458   x[1] = 0x0000000000000538   x[2] = 0x0000000000000000   x[3] = 0x0000000000000000
 x[4] = 0x0000000000000001   x[5] = 0x0000000000000000   x[6] = 0x0095000004220122   x[7] = 0x0000000000000001
 x[8] = 0x0000000000000008   x[9] = 0x0000000000000000  x[10] = 0x0000000000000000  x[11] = 0x0000000000000000
x[12] = 0x0000000000000020  x[13] = 0x0000000110904040  x[14] = 0x0000000000000000  x[15] = 0x0000000106251910
x[16] = 0x0000000104190960  x[17] = 0x0000000000200018  x[18] = 0x0000000000000000  x[19] = 0x000000010f5d3488
x[20] = 0x0000000109ca03f0  x[21] = 0x0000000102a53458  x[22] = 0x0000000109ca03f0  x[23] = 0x0000000109cc0078
x[24] = 0x00040c0000fd77c4  x[25] = 0x0000010000000000  x[26] = 0x00000002287898f8  x[27] = 0x0000000000000000
x[28] = 0x000000016f50f0e0     fp = 0x000000016f50ee00     lr = 0x0000000102cbe360     sp = 0x000000016f50edc0
ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x2a380) in __tsan::ThreadClock::release(__tsan::DenseSlabAllocCache*, __tsan::SyncClock*)+0x174
==373==ABORTING
```
jpsim added a commit that referenced this issue Jan 17, 2023
@jpsim
[CI] Remove 'TSan Runs' job (#4701)
d120f41 
This frequently crashes and I don't think it's due to a real TSan race.

E.g. https://buildkite.com/swiftlint/swiftlint/builds/4912#0185c098-a803-4525-8df1-827d1c97ed01

```
swiftlint(373,0x1ecdd3a80) malloc: nano zone abandoned due to inability to preallocate reserved vm space.
Linting Swift files in current working directory
1 of 538 [                              ] ETA: 0s (13129 files/s)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
ThreadSanitizer:DEADLYSIGNAL
==373==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000102cbe380 bp 0x00016f50ee00 sp 0x00016f50edc0 T30753687)
==373==The signal is caused by a UNKNOWN memory access.
==373==Hint: address points to the zero page.
    #0 __tsan::ThreadClock::release(__tsan::DenseSlabAllocCache*, __tsan::SyncClock*) <null>:46801128 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x2a380)
    #1 __tsan::Release(__tsan::ThreadState*, unsigned long, unsigned long) <null>:46801128 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x7456c)
    #2 swift::runJobInEstablishedExecutorContext(swift::Job*) <null>:46801128 (libswift_Concurrency.dylib:arm64e+0x40588)
    #3 swift_job_runImpl(swift::Job*, swift::ExecutorRef) <null>:46801128 (libswift_Concurrency.dylib:arm64e+0x41404)
    #4 _dispatch_root_queue_drain <null>:46801128 (libdispatch.dylib:arm64e+0x15f90)
    #5 _dispatch_worker_thread2 <null>:46801128 (libdispatch.dylib:arm64e+0x167bc)
    #6 _pthread_wqthread <null>:46801128 (libsystem_pthread.dylib:arm64e+0x30c0)
    #7 start_wqthread <null>:46801128 (libsystem_pthread.dylib:arm64e+0x1e1c)

==373==Register values:
 x[0] = 0x0000000102a53458   x[1] = 0x0000000000000538   x[2] = 0x0000000000000000   x[3] = 0x0000000000000000
 x[4] = 0x0000000000000001   x[5] = 0x0000000000000000   x[6] = 0x0095000004220122   x[7] = 0x0000000000000001
 x[8] = 0x0000000000000008   x[9] = 0x0000000000000000  x[10] = 0x0000000000000000  x[11] = 0x0000000000000000
x[12] = 0x0000000000000020  x[13] = 0x0000000110904040  x[14] = 0x0000000000000000  x[15] = 0x0000000106251910
x[16] = 0x0000000104190960  x[17] = 0x0000000000200018  x[18] = 0x0000000000000000  x[19] = 0x000000010f5d3488
x[20] = 0x0000000109ca03f0  x[21] = 0x0000000102a53458  x[22] = 0x0000000109ca03f0  x[23] = 0x0000000109cc0078
x[24] = 0x00040c0000fd77c4  x[25] = 0x0000010000000000  x[26] = 0x00000002287898f8  x[27] = 0x0000000000000000
x[28] = 0x000000016f50f0e0     fp = 0x000000016f50ee00     lr = 0x0000000102cbe360     sp = 0x000000016f50edc0
ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x2a380) in __tsan::ThreadClock::release(__tsan::DenseSlabAllocCache*, __tsan::SyncClock*)+0x174
==373==ABORTING
```
@LowAmmo LowAmmo mentioned this issue Aug 24, 2023
Closed
2 tasks
@JaviSoto JaviSoto mentioned this issue Mar 11, 2024
Open
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@eneko @jpsim @aarondaub