Add return type to functions in global namespace

Created on 17 March 2025, 23 days ago

Problem/Motivation

Following on from 📌 [META] Add return types to hook implementations Active there are thousands of functions without return types. The next bunch of low hanging fruit here is procedural functions in the global namespace. These should be simple because there is no BC concern, i.e. they don't belong to an interface or class and therefore can't be extended.

Steps to reproduce

grep -oP 'Function \K[^D].*(?=\\\\\(\\\\\) has no return type specified)' core/.phpstan-baseline.php

That lists 255 functions with no return type.

Proposed resolution

Determine how to split this issue, then add return type to each function.

Possibly we can split by prefix, then review the remaining 118 functions:

  • locale (34)
  • install (22)
  • update (22)
  • views (19)
  • simpletest (16)
  • user (14)
  • batch (10)
  • filter (10)

Or we can just do it all in one go.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

other

Created by

🇦🇺Australia mstrelan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mstrelan
  • 🇮🇳India lavanyatalwar

    Working on it.

  • Merge request !11501Automatic rector fixes → (Open) created by mstrelan
  • Pipeline finished with Failed
    23 days ago
    Total: 166s
    #449987
  • 🇦🇺Australia mstrelan

    Pushed my work so far using the rector rules in the IS to MR !11501. There are 67 functions remaining, using the steps to reproduce.

  • Pipeline finished with Success
    23 days ago
    Total: 497s
    #449990
  • 🇦🇺Australia mstrelan

    Pushed some manual updates, this is down to 39 now. Definitely leaning towards getting void returns in first then splitting the rest.

  • Pipeline finished with Success
    23 days ago
    Total: 623s
    #450006
  • 🇳🇿New Zealand quietone

    I agree, voids are the easiest to review.

  • Pipeline finished with Success
    20 days ago
    Total: 1003s
    #452850
  • Pipeline finished with Success
    13 days ago
    Total: 616s
    #458320
  • Pipeline finished with Success
    13 days ago
    Total: 1831s
    #458329
  • 🇦🇺Australia mstrelan

    Now that the low-hanging fruit is committed I've rebased the MR and commented on some of the less obvious changes. I've updated the issue summary with a proposed resolution on how to split the remaining work. Setting NR for agreement on that approach, and for eyes on the MR.

Production build 0.71.5 2024