-
-
Notifications
You must be signed in to change notification settings - Fork 668
[stable] Don't merge function types with unknown return type #21350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stable] Don't merge function types with unknown return type #21350
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: