[permission_handler_windows] Fix clang-cl compilation

[Kataglyphis]

Description

This PR fixes compilation of the Windows plugin with clang-cl (LLVM), which some projects use for faster Windows builds.

MSVC accepts the implicit conversion from EncodableMap to EncodableValue when calling MethodResult::Success(). clang-cl is stricter and rejects it.

Reproduction

Configured the way a project on the LLVM toolset does — /W3, -Wno-error — compiling the plugin target against the released 0.2.2 package with no patches applied:

$ cmake --build . --target permission_handler_windows_plugin
permission_handler_windows_plugin.cpp(142,13): error: no matching member function for call to 'Success'
  142 |     result->Success(requestResults);
   29 |   void Success(const T& result) { SuccessInternal(&result); }
   33 |   void Success() { SuccessInternal(nullptr); }
1 warning and 1 error generated.

Applying only the Success(flutter::EncodableValue(...)) change from this PR, and altering nothing else, that target compiles. This is an overload-resolution error, not a warning, so no -Wno-... flag makes it go away — a project on clang-cl currently cannot build this package without patching it locally.

Changes

Scoped entirely to permission_handler_windows, and to that one file:

1. Explicit type conversion — wrapped requestResults in flutter::EncodableValue(...) before passing it to result->Success().
   • Fixes: no matching member function for call to 'Success'
2. Warning cleanup for the /W4 /WX settings Flutter generates for every Windows app:
   • removed the unused this capture and the unused parameter names from the Geolocator.PositionChanged lambda — clang-cl reports these as -Wunused-lambda-capture and -Wunused-parameter (MSVC stays quiet on the latter because Flutter passes /wd"4100", a quoted form clang-cl does not apply);
   • gave the request loop a size_t index, fixing the signed/unsigned comparison.
3. Version — bumped permission_handler_windows to 0.2.3 with a CHANGELOG.md entry.

The app-facing permission_handler package is deliberately not touched: its existing permission_handler_windows: ^0.2.2 constraint already allows 0.2.3.

Testing

• Compiles with clang-cl — verified in a project that builds its whole Flutter app with the LLVM toolset (https://github.com/Kataglyphis/Kataglyphis-Inference-Engine): the plugin compiles from these sources with no local patching, and its DLL is installed into the app bundle. That project had been carrying a local patch for exactly this Success() call, which these changes make unnecessary.
• The changed code is MSVC-clean too: with the /await line removed locally, flutter build windows --release of the example builds the whole app on MSVC 14.51. Left in place, the package still fails there for the pre-existing reason in note 2 below — that is not something this PR changes either way.
• Verified requestPermissions still returns correct results on Windows.

Two unrelated problems I ran into while verifying this, both already on main and neither addressed here — happy to open separate PRs if useful:

1. permission_handler_windows/example cannot build: its pubspec.yaml still declares packages/baseflow_plugin_template/logo.png and poweredByBaseflow.png, but baseflow_plugin_template 2.2.0 moved those out of lib/ and declares them itself, so flutter build windows stops at No file or variants found for asset before the compiler runs. The apple, android and html examples already dropped those two lines.
2. windows/CMakeLists.txt passes /await. On MSVC 14.51 that now fails the build outright — error C2338: static assertion failed: 'error STL1011: The /await compiler option ... will be REMOVED SOON' — and under Flutter's default /W4 /WX clang-cl rejects it as an unused argument. The target already requires C++20, so <coroutine> supersedes it and the flag can simply go.

Note
This branch was rebuilt on top of current main to resolve an earlier merge conflict. A previous revision of this PR bumped permission_handler to 12.0.2 and permission_handler_windows to 0.2.2; both have since been released upstream with different contents, so those version changes were dropped.

Related Issue

Fixes build failures for users compiling the Windows plugin with clang-cl.

Pre-launch Checklist

• I made sure the project builds.
• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I rebased onto main.
• I added new tests to check the change I am making, or this PR does not need tests.
• I made sure all existing and new tests are passing.
• I ran dart format . and committed any changes.
• I ran flutter analyze and fixed any errors.

[Copilot]

Pull request overview

This PR improves compatibility with clang-cl (LLVM) compiler for the Windows permission handler plugin by making implicit type conversions explicit and cleaning up compiler warnings. The changes ensure the plugin builds successfully with both clang-cl and MSVC.

Changes:

• Made EncodableValue type conversion explicit when passing EncodableMap to result->Success()
• Removed unused [this] lambda capture that caused warnings in clang-cl
• Updated version numbers for both permission_handler_windows (0.2.1 → 0.2.2) and permission_handler (12.0.1 → 12.0.2)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
permission_handler_windows/windows/permission_handler_windows_plugin.cpp	Explicit EncodableValue conversion and removed unused lambda capture
permission_handler_windows/pubspec.yaml	Version bump to 0.2.2
permission_handler_windows/CHANGELOG.md	Added changelog entry for clang-cl support
permission_handler/pubspec.yaml	Version bump to 12.0.2 and updated Windows dependency
permission_handler/CHANGELOG.md	Added changelog entry for Windows compatibility update

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing closing backtick after result->Success(). The line should end with a closing backtick to properly format the inline code.

Suggested change

	* Explicit Type Conversion: Wrapped `requestResults` in `flutter::EncodableValue(...)` before passing it to `result->Success()
	* Explicit Type Conversion: Wrapped `requestResults` in `flutter::EncodableValue(...)` before passing it to `result->Success()`

[Kataglyphis]

Rebuilt this branch on top of current main to resolve the merge conflict, and squashed it into a single commit.

Summary of what changed since the last revision:

• Dropped the version bumps that caused the conflict. permission_handler_windows 0.2.2 and permission_handler 12.0.2/13.x have all been released upstream since this PR was opened, so the original bumps collided with released versions. The Windows package is now bumped to 0.2.3 instead.
• Removed all changes to the app-facing permission_handler package. The existing permission_handler_windows: ^0.2.2 constraint already permits 0.2.3, so no bump is required there. This was also the cause of the failing App facing package check: the PR pointed the constraint at ^0.2.2 while 0.2.2 was not yet on pub.dev, so flutter pub get could not resolve. With permission_handler/** untouched, that path-filtered workflow no longer runs for this PR.
• @Copilot's note about the unterminated backtick in the changelog is addressed — the entry was rewritten.

The PR is now three files, all inside permission_handler_windows: the two-line C++ fix, the version bump, and the changelog entry. No conflicts remain.