Skip to content

Conversation

@kinke
Copy link
Contributor

@kinke kinke commented May 6, 2025

As that can cause a 'compatible' function type with resolved return type to wrongly get that deco. This is what happens with LDC for a particular test case as D v2.111 regression, causing an assertion in the frontend while generating a TypeInfo_Function for some TypeFunction, with TypeFunction.next being null (unknown return type).

The relevant genTypeInfo() calls before the patch, in the format genTypeInfo: <type> (<deco>), <type after merge2()> (<deco after merge2()>):

// const funcptr: TypeInfo_Const
genTypeInfo: const(Algebraic!() function(Function) nothrow @system) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @system) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl)
// mutable funcptr: TypeInfo_Pointer
genTypeInfo: Algebraic!() function(Function) nothrow @system (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @system (PFNbC4util8FunctionZSQq__T9AlgebraicZQl)
// function: TypeInfo_Function
// NOTE the missing Algebraic return type in the decos, this is the bug
genTypeInfo: nothrow @system Algebraic!()(Function) (FNbC4util8FunctionZ), nothrow @system (Function) (FNbC4util8FunctionZ)

With this patch:

genTypeInfo: const(Algebraic!() function(Function) nothrow @system) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @system) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl)
genTypeInfo: Algebraic!() function(Function) nothrow @system (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @system (PFNbC4util8FunctionZSQq__T9AlgebraicZQl)
genTypeInfo: nothrow @system Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl), nothrow @system Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl)

As that can cause a 'compatible' function type with resolved return type
to wrongly get that deco. This is what happens with LDC for a particular
test case as D v2.111 regression, causing an assertion in the frontend
while generating a TypeInfo_Function for some TypeFunction, with
`TypeFunction.next` being null (unknown return type).

The relevant `genTypeInfo()` calls before the patch, in the format
`genTypeInfo: <type> (<deco>), <type after merge2()> (<deco after merge2()>)`:
```
// const funcptr: TypeInfo_Const
genTypeInfo: const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl)
// mutable funcptr: TypeInfo_Pointer
genTypeInfo: Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl)
// function: TypeInfo_Function
// NOTE the missing Algebraic return type in the decos, this is the bug
genTypeInfo: nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZ), nothrow @System (Function) (FNbC4util8FunctionZ)
```

With this patch:
```
genTypeInfo: const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl), const(Algebraic!() function(Function) nothrow @System) (xPFNbC4util8FunctionZSQq__T9AlgebraicZQl)
genTypeInfo: Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl), Algebraic!() function(Function) nothrow @System (PFNbC4util8FunctionZSQq__T9AlgebraicZQl)
genTypeInfo: nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl), nothrow @System Algebraic!()(Function) (FNbC4util8FunctionZSQq__T9AlgebraicZQl)
```
@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @kinke! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "stable + dmd#21350"

@kinke kinke changed the title Don't merge function types with unknown return type [stable] Don't merge function types with unknown return type May 6, 2025
kinke added a commit to kinke/ldc that referenced this pull request May 6, 2025
@kinke
Copy link
Contributor Author

kinke commented May 6, 2025

Unfortunately I wasn't able to quickly put together a testcase that would fail with DMD too.

@rainers: You're at least somewhat familiar with that type-merging stuff, right? Does the patch seem reasonable to you?

@kinke kinke marked this pull request as ready for review May 6, 2025 18:28
@rainers
Copy link
Member

rainers commented May 9, 2025

Yeah, I agree it's not reasonable to merge incomplete types. Not sure if the actual error is not somewhere earlier that allows such a function type with next being null to exist.

kinke added a commit that referenced this pull request May 12, 2025
@kinke kinke added Merge:72h no objection -> merge The PR will be merged if there are no objections raised. Merge:auto-merge labels May 15, 2025
@dlang-bot dlang-bot merged commit c18e2a5 into dlang:stable May 19, 2025
83 of 87 checks passed
@kinke kinke deleted the dont_merge_incomplete_typefunction branch May 19, 2025 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Merge:auto-merge Merge:72h no objection -> merge The PR will be merged if there are no objections raised.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants