Skip to content
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

Add overriding for function trait for manual implemented functions #798

Merged
merged 1 commit into from Jun 23, 2019

Conversation

@EPashkin
Copy link
Member

EPashkin commented Jun 22, 2019

Fix #797

@GuillaumeGomez, not sure that it right way, but it works

test for gio:

+++ b/Gir.toml
@@ -664,11 +664,13 @@ manual_traits = ["SocketListenerExtManual"]
     name = "accept_socket_async"
     # finish function misses nullable return annotation
     ignore = true
+    doc_trait_name = "SocketListenerExtManual"
 
     [[object.function]]
     name = "accept_async"
     # finish function misses nullable return annotation
     ignore = true
+    doc_trait_name = "SocketListenerExtManual"
 
 [[object]]
 name = "Gio.Subprocess"
@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 22, 2019

Signal need this too 😢

@EPashkin EPashkin force-pushed the EPashkin:function_doc_trait_name branch from 57e0b09 to 569d473 Jun 22, 2019
@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 22, 2019

Properties too, it also generated wrong function_name:

<!-- trait CellRendererPixbufExt::fn set_property_icon-name -->
The name of the themed icon to display.
This property only has an effect if not overridden by "stock_id"
or "pixbuf" properties.
@EPashkin EPashkin force-pushed the EPashkin:function_doc_trait_name branch from 569d473 to b518ffc Jun 22, 2019
@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 22, 2019

I hope that this final version,
@GuillaumeGomez I will process other crates tomorrow, if you don't want do it yourself

@EPashkin EPashkin force-pushed the EPashkin:function_doc_trait_name branch 2 times, most recently from a2ef452 to 19a385d Jun 22, 2019
@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 23, 2019

Checked all gtk-rs crates: PR covered all cases.
@GuillaumeGomez, @sdroege plase, check code.
Also maybe you have better solution than doc_trait_name?

@EPashkin EPashkin force-pushed the EPashkin:function_doc_trait_name branch from 19a385d to 31c723f Jun 23, 2019
@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Jun 23, 2019

Isn't it possible to get if the function is in a manual trait directly instead of adding this new key?

@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 23, 2019

Theoretically we can scan all manual files and store all traits and its functions, then auto-detect its docs,
but at the moment I don't want do parse yourself and use syn too.

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Jun 23, 2019

No need to have a super efficient thing. A little python script which will run through src folder and store all "trait *ExtManual" things should be enough no?

@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 23, 2019

We have many traits like EditableSignals in gtk, so trait name can be any,
and it require parsing anyway.
Also I don't understand how "little python script" helps with "Isn't it possible to get if the function is in a manual trait directly instead of adding this new key?"

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Jun 23, 2019

Also I don't understand how "little python script" helps with "Isn't it possible to get if the function is in a manual trait directly instead of adding this new key?"

Nothing, sorry. I thought you were talking about finding missing declared manual traits in the gir files... What I meant initially was: "why not using manual_trait = "SomeExtManual" when generating docs instead of adding a new key?

@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 23, 2019

I meant initially was: "why not using manual_trait = "SomeExtManual" when generating docs instead of adding a new key?

Mostly because it array manual_traits = ["DialogExtManual"],
also I don't think that all ignored need moved to it.

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Jun 23, 2019

It seems weird to me that it's not possible to just base ourselves on this... What do you think of this @sdroege ?

@EPashkin

This comment has been minimized.

Copy link
Member Author

EPashkin commented Jun 23, 2019

Ok, I still think that we can't change trait for all ignored functions,
so I merge this as is.

@EPashkin EPashkin merged commit 20feecf into gtk-rs:master Jun 23, 2019
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@EPashkin EPashkin deleted the EPashkin:function_doc_trait_name branch Jun 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.