Avoid unicode filename #78
Merged
Conversation
This file contains 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
|
Test failures are legit. Also there's probably 2~3 comments to update. |
tbg
force-pushed
the
non-ascii-file
branch
2 times, most recently
from
9ec113c
to
b392e85
Compare
|
Thanks! Tests should be passing now. I looked for comments that needed changes ( |
maruel
reviewed
May 12, 2022
Codecov Report
@@ Coverage Diff @@
## main #78 +/- ##
=====================================
Coverage 82.1% 82.1%
=====================================
Files 12 12
Lines 2761 2761
=====================================
Hits 2267 2267
Misses 423 423
Partials 71 71 Continue to review full report at Codecov.
|
This is similar to 53e9d3e. Over at https://github.com/cockroachdb/cockroach, we use bazel and it chokes on this file: ``` java.io.IOException: Error extracting [...]/com_github_maruel_panicparse_v2-v2.2.1.zip to [...]: [...]/com_github_maruel_panicparse_v2/cmd/panic/internal/utf8/?tf8.go (Illegal byte sequence) ``` which is why we're on a fork so far. It would be nice to avoid this. There is an (eternal, it seems) [upstream discussion], so there is little home of bazel starting to support non-unicode filenames. I wonder if the loss in test coverage (if any) is acceptable in return for avoiding build problems like the ones we've been seeing. [upstream discussion]: bazelbuild/bazel#374
|
Thanks! |
|
Published new release: https://github.com/maruel/panicparse/releases/tag/v2.2.2 |
|
Wonderful, thanks a lot Marc-Antoine. |
tbg
added a commit
to tbg/cockroach
that referenced
this pull request
May 13, 2022
This is a reincarnation of cockroachdb#81089, which was reverted in cockroachdb#81126. This time around, we pick up upstream PR [78] which renames the unicode file that prompted cockroachdb#81126. [78]: maruel/panicparse#78 Release note: None
tbg
added a commit
to tbg/cockroach
that referenced
this pull request
May 13, 2022
This is a reincarnation of cockroachdb#81089, which was reverted in cockroachdb#81126. This time around, we pick up upstream PR [78] which renames the unicode file that prompted cockroachdb#81126. [78]: maruel/panicparse#78 Release note: None
craig bot
pushed a commit
to cockroachdb/cockroach
that referenced
this pull request
May 14, 2022
81240: vendor: bump panicparse to v2.2.2 r=HonoreDB,rickystewart a=tbg This is a reincarnation of #81089, which was reverted in #81126. This time around, we pick up upstream PR [78] which renames the unicode file that prompted #81126. [78]: maruel/panicparse#78 Release note: None Co-authored-by: Tobias Grieger <tobias.b.grieger@gmail.com>
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.
This is similar to 53e9d3e.
Over at https://github.com/cockroachdb/cockroach, we use bazel and it
chokes on this file:
which is why we're on a fork so far. It would be nice to avoid this.
There is an (eternal, it seems) upstream discussion, so there is
little home of bazel starting to support non-unicode filenames.
I wonder if the loss in test coverage (if any) is acceptable in return
for avoiding build problems like the ones we've been seeing.