Skip to content

evdev-rs: Update a # Safety comment#4803

Open
RAOF wants to merge 2 commits intomainfrom
update-evdev-rs-comment
Open

evdev-rs: Update a # Safety comment#4803
RAOF wants to merge 2 commits intomainfrom
update-evdev-rs-comment

Conversation

@RAOF
Copy link
Copy Markdown
Contributor

@RAOF RAOF commented Mar 30, 2026

No description provided.

@RAOF RAOF requested a review from a team as a code owner March 30, 2026 07:10
Copilot AI review requested due to automatic review settings March 30, 2026 07:10
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Updates the Rust-side # Safety documentation around an unsafe call in the evdev-rs input event processing path, aiming to better justify the use of pin_mut_unchecked() when removing devices from the C++ InputDeviceRegistry.

Changes:

  • Replaced a generic safety note with a more specific explanation referencing cxx-rs and SharedPtr<Opaque>.
  • Clarified the intended safety rationale for calling remove_device() through pin_mut_unchecked().

Comment on lines +171 to +173
// InputDeviceRegistry is an opaque C++ type; cxx-rs guarantees that calling
// pin_mut_unchecked on a SharedPtr<Opaque> is safe for calling thread-safe
// non-const member functions (which `remove_device` is).
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

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

The updated # Safety justification is likely inaccurate/misleading: cxx::SharedPtr::pin_mut_unchecked() is unsafe because Rust cannot prove unique/exclusive mutable access from a shared_ptr (and cannot validate thread-safety or const-correctness of the underlying C++ method). Rather than saying “cxx-rs guarantees … is safe”, document the actual invariants you are asserting here (e.g., no other Rust/C++ aliases are used concurrently for this object, and the C++ type internally synchronizes any shared mutation if it can be accessed from multiple threads).

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I tend to agree with copilot here: it is the underlying C++ (shared_ptr<>) that provides any guarantee, not pin_mut_unchecked() itself.

Copy link
Copy Markdown
Contributor Author

@RAOF RAOF Mar 30, 2026

Choose a reason for hiding this comment

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

Copilot is incorrect here; cxx-rs provides the guarantee that cxx::SharedPtr::pin_mut_unchecked() is sound for calling (thread-safe) methods on opaque C++ types regardless of whether other references exist.

std::Pin has significant invariants that are not provided by std::shared_ptr.

Specifically, the invariant that I'm asserting here is that InputDeviceRegistry is an opaque C++ type (which is the invariant that cxx-rs requires for its invariants to be upheld).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

OK, I RTFM'd: "For the special case of CXX opaque C++ types, this method can be used to safely call thread-safe non-const member functions on a C++ object without regard for whether the reference is exclusive."

That wasn't my initial reading of the proposed comment, but I now see what you mean.

Comment on lines +171 to +173
// InputDeviceRegistry is an opaque C++ type; cxx-rs guarantees that calling
// pin_mut_unchecked on a SharedPtr<Opaque> is safe for calling thread-safe
// non-const member functions (which `remove_device` is).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

OK, I RTFM'd: "For the special case of CXX opaque C++ types, this method can be used to safely call thread-safe non-const member functions on a C++ object without regard for whether the reference is exclusive."

That wasn't my initial reading of the proposed comment, but I now see what you mean.

@AlanGriffiths AlanGriffiths added this pull request to the merge queue Mar 31, 2026
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to a conflict with the base branch Mar 31, 2026
@AlanGriffiths AlanGriffiths enabled auto-merge March 31, 2026 13:04
@github-actions
Copy link
Copy Markdown

TICS Quality Gate

✔️ Passed

mir

Coding Standards: ✔️ Passed

✔️ Condition “No new Coding Standard Violations for level 1, 2, 3 with respect to Previous analysis” passed.

See the results in the TICS Viewer

The following files have been checked for this project
  • src/platforms/evdev-rs/src/event_processing.rs

TICS / TICS / Run TICS analysis

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants