Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Scalafmt two scalalib/overrides* files#4605

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
LeeTibbert wants to merge1 commit intoscala-native:main
base:main
Choose a base branch
Loading
fromLeeTibbert:PR_build_Scalafmt_2025-10-31T1023-0400

Conversation

@LeeTibbert
Copy link
Contributor

@LeeTibbertLeeTibbert commentedOct 31, 2025
edited
Loading

Prior to this PR runningscripts/scalafmt orcheck-lint.sh on a freshly fetched copy of the SN Repository
in preparation for submitting a PR would show twoscalalib/override* files as modified.

This PR allows a 'round trip' of fetching the SN repository, making a few point changes, and then
pushing back to the SN repository as a PR.

Reviewers

There may be a reason, such as the files being copied 'as-is' from somewhere else in the Scala
development environment and wanting to minimize non-semantic changes. In that case,
it might be able to list them in a .gitignore.

Later:

.gitignore and it has a linescalalib/src/ but nothing I could see forscalalib/overrides.
Perhaps adding such is the preferred solution?

I would have to determine the proper syntax forscalalib/overrides and below.
Small Matter of Programming.

Later:
Right "Small", everything is SMOP until you are the one doing it ;-)

If discovered/re-learned that addingscalalib/overrides will indeed ignore
that directory and its descendants. Good so far.

The difficulty seems to be that files at or below the just added line
that are already in the Repository will not be ignored. Fixing things
up seems to involve saving a copy of the file, deleting it from the repository,
then adding it back in. Error prone surgery to a critical area.

During CI wait time I'll rat around the GitHub docs and the wider Web
to see if there is a less anxiety producing solution, such as renaming.

SMOP, Right!

Please advise as time allows.

*@example {{{
* object Main extends App {
*@example
* {{{object Main extends App {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This area looks like it shouldn't have been changed with the{{{ ... }}} block but maybe there was a formatting issue to begin with.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thank you for noticing the difference. I used the repositoryscripts/scalafmt with no local
modifications. That should have used the JVM variant of scalafmt with the preferred
.scalafmt. Easy peasy!

Your thoughts? Beyond "silly person, why did you touch this in the first place?"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

all scaladoc tags (@example in this case) are formatted with [some of] their parameters on the same line, but anything that is not a parameter (for instance, body of the tag) is formatted on the next line. tags with parameters are, for example,@param and@throws.

@LeeTibbertLeeTibbert marked this pull request as draftOctober 31, 2025 16:06
@LeeTibbert
Copy link
ContributorAuthor

A possible least-effort/greatest benefit solution is to let these two files merge
AND also add magic to .gitignore so that future files are skipped.

All the rest of the files currently in the repository are formatted. Dissonance
arises when somebody edits one of them in the future and expects it to be
ignored. Worst case, they get a 'needs scalafmt`, it gets manually formatted,
and we have another mismatch with whatever upstream involved.

Is there a way to drop a .scalafmt in that directory which matches upstream?
I am presuming there is a good reason why SN differs from upstream.

Copy link
Contributor

@kitbellewkitbellew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@LeeTibbert you should abandon, since@WojciechMazur said we shouldn't be formatting scalalib.

I think I know why you saw these files re-formatted. I will submit a PR to fix it.

*@example {{{
* object Main extends App {
*@example
* {{{object Main extends App {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

all scaladoc tags (@example in this case) are formatted with [some of] their parameters on the same line, but anything that is not a parameter (for instance, body of the tag) is formatted on the next line. tags with parameters are, for example,@param and@throws.

@WojciechMazur
Copy link
Contributor

The issue is more likekly the exclude pattern in scalafmt config

   "glob:**/scala-native/scalalib/**"

I belive it should be

   "glob:**/scalalib/**"

If you've cloned the repo under different name it would not match the glob.
We should not format any sources in scalalib directory

@LeeTibbert
Copy link
ContributorAuthor

Status:

I am leaving this Issue open until I have done a few private design studies for other Issues. Those
should show if the Issue is fixed. I expect it to be, but want to verify.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

2 more reviewers

@ekrichekrichekrich left review comments

@kitbellewkitbellewkitbellew left review comments

Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@LeeTibbert@WojciechMazur@ekrich@kitbellew

[8]ページ先頭

©2009-2025 Movatter.jp