8000 Bump version to 0.2.0 · SwiftDocOrg/SwiftSemantics@407b1ab · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Oct 17, 2021. It is now read-only.

Commit 407b1ab

Browse files
matttmattt
committed
Bump version to 0.2.0
1 parent ea61413 commit 407b1ab

File tree

2 files changed

+37
-30
lines changed

2 files changed

+37
-30
lines changed

‎Changelog.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
77

88
## [Unreleased]
99

10+
## [0.2.0] - 2020-11-11
11+
1012
### Added
1113

1214
- Added support for Swift 5.3.
@@ -39,7 +41,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
3941

4042
Initial release.
4143

42-
[unreleased]: https://github.com/SwiftDocOrg/swift-doc/compare/0.1.0...master
44+
[unreleased]: https://github.com/SwiftDocOrg/swift-doc/compare/0.2.0...master
45+
[0.2.0]: https://github.com/SwiftDocOrg/SwiftSemantics/releases/tag/0.2.0
4346
[0.1.0]: https://github.com/SwiftDocOrg/SwiftSemantics/releases/tag/0.1.0
4447
[0.0.2]: https://github.com/SwiftDocOrg/SwiftSemantics/releases/tag/0.0.2
4548
[0.0.1]: https://github.com/SwiftDocOrg/SwiftSemantics/releases/tag/0.0.1

‎README.md

Lines changed: 33 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
SwiftSemantics is a package that lets you
77
parse Swift code into its constituent declarations.
88

9-
Use [SwiftSyntax][swiftsyntax] to construct
9+
Use [SwiftSyntax][swiftsyntax] to construct
1010
an abstract syntax tree from Swift source code,
1111
then walk the AST with the provided `DeclarationCollector`
1212
(or with your own `SyntaxVisitor`-conforming type)
@@ -63,14 +63,14 @@ collector.variables[2].modifiers.first?.detail // "set"
6363
> For more information about SwiftSyntax,
6464
> see [this article from NSHipster][nshipster swiftsyntax].
6565
66-
This package is used by [swift-doc][swift-doc]
67-
in coordination with [SwiftMarkup][swiftmarkup]
66+
This package is used by [swift-doc][swift-doc]
67+
in coordination with [SwiftMarkup][swiftmarkup]
6868
to generate documentation for Swift projects
6969
_([including this one][swiftsemantics documentation])_.
7070

7171
## Requirements
7272

73-
- Swift 5.1+
73+
- Swift 5.2 or 5.3
7474

7575
## Installation
7676

@@ -79,18 +79,22 @@ _([including this one][swiftsemantics documentation])_.
7979
Add the SwiftSemantics package to your target dependencies in `Package.swift`:
8080

8181
```swift
82+
// swift-tools-version:5.3
83+
8284
import PackageDescription
8385

8486
let package = Package(
8587
name: "YourProject",
8688
dependencies: [
8789
.package(
90+
name: "SwiftSemantics",
8891
url: "https://github.com/SwiftDocOrg/SwiftSemantics",
89-
from: "0.0.1"
92+
from: "0.2.0"
9093
),
9194
.package(
92-
url: "https://github.com/apple/swift-syntax.git",
93-
from: "0.50100.0"
95+
name: "SwiftSyntax",
96+
url: "https://github.com/apple/swift-syntax.git",
97+
from: "0.50300.0"
9498
),
9599
]
96100
)
@@ -102,7 +106,7 @@ Then run the `swift build` command to build your project.
102106

103107
Swift defines 17 different kinds of declarations,
104108
each of which is represented by a corresponding type in SwiftSemantics
105-
that conforms to the
109+
that conforms to the
106110
[`Declaration` protocol](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Declaration):
107111

108112
- [`AssociatedType`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/AssociatedType)
@@ -128,19 +132,19 @@ that conforms to the
128132
> as well as [unit tests](https://github.com/SwiftDocOrg/SwiftSemantics/tree/master/Tests/SwiftSemanticsTests).
129133
130134
The `Declaration` protocol itself has no requirements.
131-
However,
132-
adopting types share many of the same properties,
133-
such as
135+
However,
136+
adopting types share many of the same properties,
137+
such as
134138
[`attributes`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Class#attributes),
135-
[`modifiers`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Class#modifiers),
139+
[`modifiers`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Class#modifiers),
136140
and
137141
[`keyword`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Class#keyword).
138142

139143
SwiftSemantics declaration types are designed to
140144
maximize the information provided by SwiftSyntax,
141145
closely following the structure and naming conventions of syntax nodes.
142146
In some cases,
143-
the library takes additional measures to refine results
147+
the library takes additional measures to refine results
144148
into more conventional interfaces.
145149
For example,
146150
the `PrecedenceGroup` type defines nested
@@ -150,7 +154,7 @@ and
150154
enumerations for greater convenience and type safety.
151155
However, in other cases,
152156
results may be provided in their original, raw `String` values;
153-
this decision is typically motivated either by
157+
this decision is typically motivated either by
154158
concern for possible future changes to the language
155159
or simply out of practicality.
156160

@@ -163,26 +167,26 @@ There are, however, some details that warrant further discussion:
163167

164168
In Swift,
165169
a class, enumeration, or structure may contain
166-
one or more initializers, properties, subscripts, and methods,
170+
one or more initializers, properties, subscripts, and methods,
167171
known as _members_.
168172
A type can itself be a member of another type,
169173
such as with `CodingKeys` enumerations nested within `Codable`-conforming types.
170174
Likewise, a type may also have one or more associated type or type alias members.
171175

172-
SwiftSemantics doesn't provide built-in support for
176+
SwiftSemantics doesn't provide built-in support for
173177
accessing type members directly from declaration values.
174-
This is probably the most surprising
175-
(and perhaps contentious)
178+
This is probably the most surprising
179+
(and perhaps contentious)
176180
design decision made in the library so far,
177181
but we believe it to be the most reasonable option available.
178182

179183
One motivation comes down to delegation of responsibility:
180184
`DeclarationCollector` and other types conforming to `SyntaxVisitor`
181185
walk the abstract syntax tree,
182186
respond to nodes as they're visited,
183-
and decide whether to visit or skip a node's children.
187+
and decide whether to visit or skip a node's children.
184188
If a `Declaration` were to initialize its own members,
185-
it would have the effect of overriding
189+
it would have the effect of overriding
186190
the tree walker's decision to visit or skip any children.
187191
We believe that an approach involving direct member initialization is inflexible
188192
and more likely to produce unexpected results.
@@ -192,8 +196,8 @@ there wouldn't be a clear way to avoid needlessly initializing
192196
the members of each top-level class
193197
without potentially missing class declarations nested in other types.
194198

195-
But really,
196-
the controlling motivation has to do with extensions ---
199+
But really,
200+
the controlling motivation has to do with extensions ---
197201
especially when used across multiple files in a module.
198202
Consider the following two Swift files in the same module:
199203

@@ -219,7 +223,7 @@ and therefore misleading.
219223
<details>
220224
<summary><em>And if that weren't enough to dissuade you...</em></summary>
221225

222-
Consider what happens when we throw generically-constrained extensions
226+
Consider what happens when we throw generically-constrained extensions
223227
and conditional compilation into the mix...
224228

225229
```swift
@@ -240,7 +244,7 @@ reconciling declaration contexts to API consumers.
240244

241245
This is the approach we settled on for [swift-doc][swift-doc],
242246
and it's worked reasonably well so far.
243-
That said,
247+
That said,
244248
we're certainly open to hearing any alternative approaches
245249
and invite you to share any feedback about project architecture
246250
by [opening a new Issue](https://github.com/SwiftDocOrg/SwiftSemantics/issues/new).
@@ -250,13 +254,13 @@ by [opening a new Issue](https://github.com/SwiftDocOrg/SwiftSemantics/issues/ne
250254
Swift is a complex language with many different rules and concepts,
251255
and not all of them are represented directly in SwiftSemantics.
252256

253-
Declaration membership,
257+
Declaration membership,
254258
discussed in the previous section,
255259
is one such example.
256260
Another is how
257261
declaration access modifiers like `public` and `private(set)`
258262
aren't given any special treatment;
259-
they're [`Modifier`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Modifier) values
263+
they're [`Modifier`](https://github.com/SwiftDocOrg/SwiftSemantics/wiki/Modifier) values
260264
like any other.
261265

262266
This design strategy keeps the library narrowly focused
@@ -265,7 +269,7 @@ and more adaptable to language evolution over time.
265269
You can extend SwiftSemantics in your own code
266270
to encode any missing language concepts that are relevant to your problem.
267271
For example,
268-
SwiftSemantics doesn't encode the concept of
272+
SwiftSemantics doesn't encode the concept of
269273
[property wrappers](https://nshipster.com/propertywrapper/),
270274
but you could use it as the foundation of your own representation:
271275

@@ -306,9 +310,9 @@ _does_ offer this functionality.
306310

307311
## Known Issues
308312

309-
- Xcode 11 cannot run unit tests (<kbd>⌘</kbd><kbd>U</kbd>)
313+
- Xcode 11 cannot run unit tests (<kbd>⌘</kbd><kbd>U</kbd>)
310314
when opening the SwiftSemantics package directly,
311-
as opposed first to generating an Xcode project file with
315+
as opposed first to generating an Xcode project file with
312316
`swift package generate-xcodeproj`.
313317
(The reported error is:
314318
`Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib`).

0 commit comments

Comments
 (0)
0