[stable] Don't merge function types with unknown return type#21350
[stable] Don't merge function types with unknown return type#21350dlang-bot merged 1 commit intodlang:stablefrom
Conversation
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) ```
|
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 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 referencesYour 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 locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "stable + dmd#21350" |
|
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? |
|
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 |
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.nextbeing null (unknown return type).The relevant
genTypeInfo()calls before the patch, in the formatgenTypeInfo: <type> (<deco>), <type after merge2()> (<deco after merge2()>):With this patch: