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

[pigeon] Fix kotlin warning about calling bridge method#10632

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

Open
reidbaker wants to merge15 commits intoflutter:main
base:main
Choose a base branch
Loading
fromreidbaker:i_178908_bridge_call

Conversation

@reidbaker
Copy link
Contributor

@reidbakerreidbaker commentedDec 15, 2025
edited
Loading

  • Modify generated code to implement methods fromPigeonEventChannelWrapper
  • Bump tooling/yaml version, update changelog
  • update kotlin generated tests

Part 1/2 for #178908
Next step is to update video_player_android with this feature.

Tested by updating an example app to use a local version of video_player_android and manually modifying the generated files prior to updating the generator.

Pre-Review Checklist

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] page, which explains my responsibilities.
  • I read and followed the [relevant style guides] and ran [the auto-formatter].
  • I signed the [CLA].
  • The title of the PR starts with the name of the package surrounded by square brackets, e.g.[shared_preferences]
  • I [linked to at least one issue that this PR fixes] in the description above.
  • I updatedpubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].
  • I updatedCHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].
  • I updated/added any relevant documentation (doc comments with///).
  • I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
  • All existing and new tests are passing.

Copy link

@gemini-code-assistgemini-code-assistbot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request aims to fix a Kotlin "bridge method" warning by ensuring generated stream handler classes implement all methods from their supertype. The version numbers and changelog are updated accordingly. While the intent is correct, I've identified a critical issue in the Kotlin generator that places the new override methods inside thecompanion object, which will cause a compilation failure. I've provided a code suggestion to move these methods to the correct location within the class body. Additionally, I've suggested a small correction for a typo in theCHANGELOG.md file.

reidbakerand others added2 commitsDecember 15, 2025 13:19
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
}
}
// Implement methods from EventChannelMessagesPigeonEventChannelWrapper
overrideopenfunonListen(p0:Any?,sink:PigeonEventSink<PlatformEvent>) {}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does making theseabstract instead of no-ops ({}) work and fix the warning? That would be an explicit statement of the intent here, which is to not implement the interface at this level but require subclasses to implement the type-specified version.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I repro'd locally and tried it, and this does indeed seem to work:

overrideopenabstractfunonListen(p0:Any?,sink:PigeonEventSink<PlatformVideoEvent>)overrideopenabstractfunonCancel(p0:Any?)

That keeps the same semantics of forcing the subclasses to implement both methods, without tripping the warning.

reidbaker reacted with eyes emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

modifying the pr to do this instead. My goal was not to change the semantics.

Copy link
Contributor

@tarrinnealtarrinneal left a comment

Choose a reason for hiding this comment

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

lgtm once changes are made as discussed.

eventSink= sink
}

overridefunonCancel(p0:Any?) {}
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

@stuartmorgan-g@tarrinneal pigeon_example_app failed to build without this change. Does that mean this is a breaking change? If so, does that change what solution you prefer here?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry, looking again at the top-level interface class it has default implementations. I really thought it was just abstract declarations.

So your previous version of the PR was the behavior-preserving one, and I was just confused. Sorry about that!

Copy link
Collaborator

@stuartmorgan-gstuartmorgan-g left a comment

Choose a reason for hiding this comment

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

LGTM

##26.1.5

*[kotlin] Fixes a "bridge method" warning that occurs when a class uses`*PigeonEventChannelWrapper` as a
supertype without implementing all of its methods.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the "without implementing all of its methods" part right? The video_player codewas implementing both of these methods.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I am open to better wording but the class that implemented all the methods was an implementation of*EventsStreamHandler not the interface*PigeonEventChannelWrapper.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, I see. Since we don't expect Pigeon users to directly subclass theWrapper class, let's just say "... warning when implementing an event stream handler."

Copy link
Contributor

@tarrinnealtarrinneal left a comment

Choose a reason for hiding this comment

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

looks good, thanks Reid

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

Reviewers

@stuartmorgan-gstuartmorgan-gstuartmorgan-g approved these changes

@tarrinnealtarrinnealtarrinneal approved these changes

+1 more reviewer

@gemini-code-assistgemini-code-assist[bot]gemini-code-assist[bot] left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@reidbaker@stuartmorgan-g@tarrinneal

[8]ページ先頭

©2009-2025 Movatter.jp