Update Swift fork of cmark with upstream cmark repository #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We reuse the parser for reference labels, instead of just assuming that a slice of the link text will be a valid reference label. (It might contain interior brackets, for example.)
This reverts commit c069cb5.
See commonmark/commonmark.js#101 This uses a separate stack for brackets, instead of putting them on the delimiter stack. This avoids the need for looking through the delimiter stack for the next bracket. It also avoids a shortcut reference lookup when the reference text contains brackets. The change dramatically improved performance on the nested links pathological test for commonmark.js. It has a smaller but measurable effect here.
This is too strict, as it prevents the use of dynamically loaded extensions: see commonmark#123 (comment). Documented in man page and public header that one should use the same memory allocator for every node in a tree.
It is no longer needed; only the brackets struct needs it. Thanks to @robinst.
This will need corresponding spec changes.
The change is this: when considering matches between an interior
delimiter run (one that can open and can close) and another delimiter
run, we require that the sum of the lengths of the two delimiter
runs mod 3 is not 0.
Thus, for example, in
*a**b*
1 23 4
delimiter 1 cannot match 2, since the sum of the lengths of
the first delimiter run (1) and the second (1,2) == 3.
Thus we get `<em>a**b</em>` instead of `<em>a</em><em>b</em>`.
This gives better behavior on things like
*a**b**c*
which previously got parsed as
<em>a</em><em>b</em><em>c</em>
and now would be parsed as
<em>a<strong>b</strong>c</em>
With this change we get four spec test failures, but in each
case the output seems more "intuitive":
```
Example 386 (lines 6490-6494) Emphasis and strong emphasis
*foo**bar**baz*
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em>foo</em><em>bar</em><em>baz</em></p>
+<p><em>foo<strong>bar</strong>baz</em></p>
Example 389 (lines 6518-6522) Emphasis and strong emphasis
*foo**bar***
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em>foo</em><em>bar</em>**</p>
+<p><em>foo<strong>bar</strong></em></p>
Example 401 (lines 6620-6624) Emphasis and strong emphasis
**foo*bar*baz**
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em><em>foo</em>bar</em>baz**</p>
+<p><strong>foo<em>bar</em>baz</strong></p>
Example 442 (lines 6944-6948) Emphasis and strong emphasis
**foo*bar**
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p><em><em>foo</em>bar</em>*</p>
+<p><strong>foo*bar</strong></p>
```
This allows using them in other cmake projects.
It's possible that cmark_chunk_set_cstr is called with a substring (suffix) of the current string. Delay freeing of the chunk content to handle this case correctly. Fixes issue commonmark#139.
Fix chunk_set_cstr with suffix of current string
instead of going through all the formats and options and probably getting the same output.
...they start with 1.
- Remove outdated comment - Fix code block delimiter
XSLT stylesheet to convert cmark XML back to Commonmark
Add xml:space="preserve" in XML output when appropriate
This is needed for round-trip tests.
Fix a typo in houdini_href_e.c
We can't rely on anything in `subj` since it's been modified while parsing the subject and could represent line info from a future line. This is simple and works.
correct sourcepos for emphasis inlines
Use pledge(2) on OpenBSD
|
@swift-ci please test |
|
Nice! Thanks for doing this. Does this also have the local patches that were applied to CMark? Or did those get upstream'ed? |
|
Are there swift-side changes needed ? If yes, we should have a corresponding PR specific for adopting cmark changes. |
I need to manually resolve some merge conflict due to our local cmake patches. Maybe there are some local changes still there.
It doesn't seem to be. I ran Swift CI test with this patch and found only unrelated failures: |
|
@tkremenek could we take this merge with upstream repo? |
|
@nkcsgexi yes. We should decide what we want to do about |
SGTM 👍 |
|
@tkremenek I agree. We should keep swift-5.0-branch stable for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.