You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is a guide of how to write log messages and which level they should be logged at. There may be reasons to deviate from these guides but they should be a good starting point.
4
+
5
+
## Log Levels
6
+
7
+
The following log levels should be used by log messages in default. The [Explore logging in Swift](https://developer.apple.com/wwdc20/10168?time=604) session from WWDC20 has some explanation of how these levels are persisted by OS log and we follow those guidelines.
8
+
9
+
### Fault
10
+
11
+
> From Explore Logging in Swift: _Bug in program_
12
+
13
+
A bug in SourceKit-LSP, sourcekitd or any other project included in the Swift toolchain that should never happen and is not due to malformed user input. The fix for faults should always be in a project controlled by the Swift toolchain (most likely in SourceKit-LSP itself) and we should never close them as a third party to resolve. Think of these as light assertions that don’t crash sourcekit-lsp because it is able to recover in some way.
14
+
15
+
Examples:
16
+
- Some global state invariant is broken like a file to `startProgress` not being followed by `endProgress`
17
+
- sourcekitd crashes
18
+
- Two targets in SwiftPM have the same name
19
+
20
+
### Error
21
+
22
+
> From Explore Logging in Swift: _Error seen during execution_
23
+
24
+
An error that is due to user input or eg. stale state of files on disk. It indicates that something is going wrong which might explain unexpected behavior. Errors could be due to malformed user input such as invalid requests from the editor or due to stale state that will eventually converge again.
25
+
26
+
Examples:
27
+
- The client sends an invalid request
28
+
- Preparation of a file failed due to a syntax error in the user’s code
29
+
- The index contains a reference to a source file but the source fail has been modified since the index was last updated and is thus no longer valid
30
+
31
+
## Log/Notice/Default
32
+
33
+
`logger.default` logs at the `default` aka `notice` level.
34
+
35
+
> From Explore Logging in Swift: _Essential for troubleshooting_
36
+
37
+
Essential state transitions during SourceKit-LSP’s execution that allow use to determine what interactions the user performed. These logs will most likely be included in diagnose bundles from `sourcekit-lsp` diagnose and should help us solve most problems.
38
+
39
+
Examples:
40
+
- The user sends an LSP request
41
+
- Indexing of a file starts or finishes
42
+
- New build settings for a file have been computed
43
+
- Responses from sourcekitd
44
+
45
+
## Info
46
+
47
+
> From Explore Logging in Swift: _Helpful but not essential for troubleshooting_ (not persisted, logged to memory)
48
+
49
+
Internal state transitions that are helpful. If eg. a request fails and it’s not immediately obvious at which it failed, these should help us narrow down the code that it failed in. These messages might be missing from the logs generated by `sourcekit-lsp diagnose` and should not generally be needed to fix issues
50
+
51
+
Examples:
52
+
- Requests sent to `sourcekitd` or `clangd`
53
+
- Logging the main file for a header file
54
+
55
+
## Debug
56
+
57
+
> From Explore Logging in Swift: _Useful only during debugging_ (only logged during debugging)
58
+
59
+
Log messages that are useful eg. when debugging a test failure but that is not needed for diagnosing most real-world issues, like detailed information about when a function starts executing to diagnose race conditions.
60
+
61
+
Examples:
62
+
- Tasks start and finish executing in `TaskScheduler`
63
+
64
+
## Log messages
65
+
66
+
Log messages should resemble English sentences and start with an uppercase letter. If the log is a single sentence it should not have a period at its end.
0 commit comments