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.

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

Update Goldmark to Goldmark 1.4.4 #18420

Merged
merged 8 commits into from
Jan 29, 2022
Merged

Conversation

zeripath
Copy link
Contributor

Update Goldmark libraries.

I've put a PR in to goldmark-highlight that should update it to use the latest chroma.

Signed-off-by: Andrew Thornton art27@cantab.net

Signed-off-by: Andrew Thornton <art27@cantab.net>
@zeripath zeripath added this to the 1.17.0 milestone Jan 26, 2022
@GiteaBot GiteaBot added the lgtm/need 1 This PR needs approval from one additional maintainer to be merged. label Jan 27, 2022
@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Jan 27, 2022
@techknowlogick
Copy link
Member

CI fail is unrelated, but still needs to be resolved (probably for another PR though). Probably due to recent update to golangci-lint

@wxiaoguang
Copy link
Contributor

CI fail is unrelated, but still needs to be resolved (probably for another PR though). Probably due to recent update to golangci-lint

It's related, goldmark just deprecated util.FindClosure, so the code should be updated according to the new goldmark.

@lafriks
Copy link
Member

lafriks commented Jan 27, 2022

who does deprecation in revision release :/

@zeripath
Copy link
Contributor Author

I'll fix the deprecations later today. I'll block this until then.

@zeripath zeripath added the status/blocked This PR cannot be merged yet, i.e. because it depends on another unmerged PR label Jan 27, 2022
@zeripath
Copy link
Contributor Author

Lol even the file that this is deeply inspired by hasn't migrated from the deprecated function.

@zeripath
Copy link
Contributor Author

damn this is not a simple update and will require test cases - would it be ok to simply nolint this?

Signed-off-by: Andrew Thornton <art27@cantab.net>
@lunny
Copy link
Member

lunny commented Jan 28, 2022

Could we use another function?

@6543
Copy link
Member

6543 commented Jan 28, 2022

It would be a refactor ... @lunny - I can have a look in this -> ok the diff will be bigger than 5lines :D

@zeripath
Copy link
Contributor Author

The issue is in footnoteBlockParser:

func (b *footnoteBlockParser) Open(parent ast.Node, reader text.Reader, pc parser.Context) (ast.Node, parser.State) {
	line, segment := reader.PeekLine()
	pos := pc.BlockOffset()
	if pos < 0 || line[pos] != '[' {
		return nil, parser.NoChildren
	}
	pos++
	if pos > len(line)-1 || line[pos] != '^' {
		return nil, parser.NoChildren
	}
	open := pos + 1
	closes := 0
	closure := util.FindClosure(line[pos+1:], '[', ']', false, false) //nolint
	closes = pos + 1 + closure
	next := closes + 1
	if closure > -1 {
		if next >= len(line) || line[next] != ':' {
			return nil, parser.NoChildren
		}
	} else {
		return nil, parser.NoChildren
	}
...

This doesn't easily appear to map to the reader.FindClosure() code - as in the above the reader position appears to be at the start of the line so would need to be advanced to the pos and then reset as necessary.

So we'd need to write a couple of test cases to ensure that the code does the correct job if we were to refactor this to get rid of the deprecation.

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Jan 29, 2022

ps: I can accept that we use //nolint to ignore this deprecation then fix it later.

@lunny
Copy link
Member

lunny commented Jan 29, 2022

The issue is in footnoteBlockParser:

func (b *footnoteBlockParser) Open(parent ast.Node, reader text.Reader, pc parser.Context) (ast.Node, parser.State) {
	line, segment := reader.PeekLine()
	pos := pc.BlockOffset()
	if pos < 0 || line[pos] != '[' {
		return nil, parser.NoChildren
	}
	pos++
	if pos > len(line)-1 || line[pos] != '^' {
		return nil, parser.NoChildren
	}
	open := pos + 1
	closes := 0
	closure := util.FindClosure(line[pos+1:], '[', ']', false, false) //nolint
	closes = pos + 1 + closure
	next := closes + 1
	if closure > -1 {
		if next >= len(line) || line[next] != ':' {
			return nil, parser.NoChildren
		}
	} else {
		return nil, parser.NoChildren
	}
...

This doesn't easily appear to map to the reader.FindClosure() code - as in the above the reader position appears to be at the start of the line so would need to be advanced to the pos and then reset as necessary.

So we'd need to write a couple of test cases to ensure that the code does the correct job if we were to refactor this to get rid of the deprecation.

If that, I'm OK to merge it at first. But I think we have to resolve it in future version when the function will be removed.
Is there any other block things here ? Or you can remove the block label @zeripath

@zeripath zeripath removed the status/blocked This PR cannot be merged yet, i.e. because it depends on another unmerged PR label Jan 29, 2022
@codecov-commenter
Copy link

Codecov Report

Merging #18420 (44cdd1b) into main (3349fd8) will decrease coverage by 0.01%.
The diff coverage is 41.05%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main   #18420      +/-   ##
==========================================
- Coverage   46.03%   46.01%   -0.02%     
==========================================
  Files         840      842       +2     
  Lines       92856    93186     +330     
==========================================
+ Hits        42746    42883     +137     
- Misses      43323    43502     +179     
- Partials     6787     6801      +14     
Impacted Files Coverage Δ
cmd/restore_repo.go 0.00% <0.00%> (ø)
models/auth/twofactor.go 20.89% <0.00%> (-0.65%) ⬇️
models/db/engine.go 36.13% <ø> (ø)
models/issue_milestone.go 72.11% <ø> (+1.76%) ⬆️
modules/generate/generate.go 0.00% <0.00%> (ø)
modules/indexer/code/elastic_search.go 1.36% <0.00%> (-0.25%) ⬇️
modules/markup/common/footnote.go 22.01% <0.00%> (ø)
modules/migration/issue.go 100.00% <ø> (ø)
modules/private/restore_repo.go 0.00% <0.00%> (ø)
modules/queue/queue.go 37.09% <0.00%> (ø)
... and 62 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 726715f...44cdd1b. Read the comment docs.

@wxiaoguang wxiaoguang merged commit b34923d into go-gitea:main Jan 29, 2022
@zeripath zeripath deleted the goldmark-update branch January 29, 2022 13:22
zeripath added a commit to techknowlogick/gitea that referenced this pull request Mar 18, 2022
Backport go-gitea#18420

* nolint the deprecation

Signed-off-by: Andrew Thornton <art27@cantab.net>
6543 added a commit that referenced this pull request Mar 19, 2022
Backport #19120 
Backport #19099 
Backport #18874 
Backport #18420
Backport #19128
Backport #18270 

Bump to build with go1.18

Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Jelle Hulter <jellehulter@gmail.com>
Chianina pushed a commit to Chianina/gitea that referenced this pull request Mar 28, 2022
* Update Goldmark to Goldmark 1.4.4
* nolint the deprecation

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants