fix: fix error on Archlinux build

[calsys456]

Those are mostly nodiscard errors. Simply add some assertions.

Summary by Sourcery

Address file handling and Wayland connector cleanup issues uncovered during Arch Linux builds.

Bug Fixes:

• Ensure QFile::open results are checked and asserted when opening log and configuration files to satisfy nodiscard semantics and catch unexpected failures.
• Replace direct deletion of the Treeland Wayland private object with the appropriate destroy function to correctly clean up resources.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adds explicit handling for nodiscard file-open results and fixes a cleanup call in the Wayland/Treeland connector to avoid Archlinux build errors and improve error checking.

Sequence diagram for TreelandConnector setPrivateObject cleanup behavior

sequenceDiagram
    participant Client
    participant TreelandConnector
    participant TreelandDDM as treeland_ddm

    Client->>TreelandConnector: setPrivateObject(new_ddm)
    alt existing private object
        TreelandConnector->>TreelandDDM: treeland_ddm_destroy(m_ddm)
        TreelandConnector-->>TreelandConnector: m_ddm = nullptr
    end
    TreelandConnector-->>TreelandConnector: m_ddm = new_ddm

Loading

Class diagram for TreelandConnector updated ownership of treeland_ddm

classDiagram
    class TreelandConnector {
        - treeland_ddm* m_ddm
        + bool isConnected()
        + void setPrivateObject(treeland_ddm* ddm)
    }

    class treeland_ddm {
    }

    TreelandConnector ..> treeland_ddm : manages

Loading

File-Level Changes

Change	Details	Files
Handle QFile::open return values explicitly and assert success where failure is not expected.	Wrap fallback truncate-open path in a block and store QFile::open result in a local bool before asserting success when opening the log file for appending or truncating. Do the same when opening a log file in the user-writable AppDataLocation, asserting that the truncate-open call succeeds. Capture the return value of QFile::open in ConfigReader when opening the config file for read-only access and assert it succeeded. Capture and assert the return value of QFile::open when rewriting the config file with WriteOnly	Truncate flags.
Fix destruction of Treeland private object using the appropriate treeland API rather than a raw delete.	Replace manual delete of m_ddm with treeland_ddm_destroy when setting the TreelandConnector private object.	src/daemon/TreelandConnector.cpp

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[deepin-ci-robot]

Hi @calsys456. Thanks for your PR.

I'm waiting for a linuxdeepin member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Using Q_ASSERT(ok) after file.open(...) changes the behavior to abort in debug builds when the file cannot be opened; if this failure is expected/possible in normal operation, consider explicitly handling the error (e.g., early return or fallback path) instead of asserting, and use (void)file.open(...) or [[maybe_unused]] on ok to satisfy the nodiscard warning.
• In ConfigReader, opening the file for read/write now relies solely on Q_ASSERT(ok) for failure handling; if opening the config file can legitimately fail (e.g., missing or unreadable file), it may be more robust to propagate or log the error instead of only asserting in debug builds.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Using `Q_ASSERT(ok)` after `file.open(...)` changes the behavior to abort in debug builds when the file cannot be opened; if this failure is expected/possible in normal operation, consider explicitly handling the error (e.g., early return or fallback path) instead of asserting, and use `(void)file.open(...)` or `[[maybe_unused]]` on `ok` to satisfy the `nodiscard` warning.
- In `ConfigReader`, opening the file for read/write now relies solely on `Q_ASSERT(ok)` for failure handling; if opening the config file can legitimately fail (e.g., missing or unreadable file), it may be more robust to propagate or log the error instead of only asserting in debug builds.

## Individual Comments

### Comment 1
<location> `src/common/MessageHandler.h:77-79` </location>
<code_context>
         if (!file.isOpen() && !isatty(STDERR_FILENO)) {
-            if (!file.open(QFile::Append | QFile::WriteOnly))
-                file.open(QFile::Truncate | QFile::WriteOnly);
+            if (!file.open(QFile::Append | QFile::WriteOnly)) {
+                bool ok = file.open(QFile::Truncate | QFile::WriteOnly);
+                Q_ASSERT(ok);
+            }

</code_context>

<issue_to_address>
**issue (bug_risk):** Asserting on `file.open` here conflicts with the intended fallback behavior for non-writable log locations.

Because we intentionally fall back to a writable location when the primary log path can’t be opened, asserting on the truncate open short-circuits that behavior: debug builds will abort instead of reaching the `if (!file.isOpen()) { ... }` fallback when the system log path is unwritable. That’s a regression for valid environments like read‑only setups.

To preserve the documented behavior while still catching unexpected errors, consider either removing this `Q_ASSERT`, only asserting after the fallback also fails, or replacing it with a logged warning. The same applies to the later `Q_ASSERT(ok)` when `file` points to `~/.local/share/.../ddm.log`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: calsys456, zccrs

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment