Add return type to functions in global namespace

Open on Drupal.org →

Created on 17 March 2025, about 2 months 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

!11501Add return type to functions in global namespace
Open
🇦🇺Australia mstrelan
updated about 1 month ago

Comments & Activities

Issue created by @mstrelan
Comment about 2 months ago →
🇮🇳India lavanyatalwar
Working on it.
Comment about 2 months ago →
🇦🇺Australia mstrelan
Merge request !11501Automatic rector fixes → (Open) created by mstrelan
Pipeline finished with Failed
about 2 months ago
Total: 166s
#449987
Comment about 2 months ago →
🇦🇺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
about 2 months ago
Total: 497s
#449990
Comment about 2 months ago →
🇦🇺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
about 2 months ago
Total: 623s
#450006
Comment about 2 months ago →
🇳🇿New Zealand quietone
I agree, voids are the easiest to review.
Pipeline finished with Success
about 2 months ago
Total: 1003s
#452850
Pipeline finished with Success
about 1 month ago
Total: 616s
#458320
Pipeline finished with Success
about 1 month ago
Total: 1831s
#458329
Comment about 1 month ago →
🇦🇺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.
Comment 3 days ago →
needs-review-queue-bot
The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024