-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
WIP: Add Configuration file and support for removing certain Rules #7
Conversation
|
||
return map(self.configuration) { | ||
filter(allRules) { | ||
return !self.configuration.shouldIgnore($0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the negation by changing the interface to shouldValidateWith
or something equivalent?
… and have it be optional
…configurationFileContents)
|
||
let fileName: String | ||
|
||
init(fileName: String? = nil) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be:
init(fileName: String = Configuration.defaultConfigurationName)
We should really be using a robust YAML parser, as the basic string parsing done here will break down pretty quickly. I can only find https://github.com/behrang/yaml.swift and https://github.com/brynbellomy/SwiftConfig for Swift, and I haven't looked into them yet, so they may not be what we need. Some research needs to be done there. There's also https://github.com/mirek/YAML.framework which is Objective-C but looks a bit more mature. |
Also, thanks for working on this and for posting a WIP PR! It's so great to see so much community interest in contributing to this so quickly. |
Yeah, I wrote this very haphazardly yesterday evening. I'm going to focus on getting the Rules to be settable (still hung up on the issue we discussed earlier) and then totally re-do this PR |
@jpsim I think we should close this in favour of PR 12 and then later open one specifically for the configuration file. |
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 ```
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 I haven't verified that this works as I can't get the repo to build. I'll update this PR once I have seen that this actually does what I want it to :)