GNOME Bugzilla – Bug 472259
Warn of conflicts of generated C identifiers
Last modified: 2018-05-22 13:01:53 UTC
A mere underscore is used to seperate class and method names in the generated C. Try this: /* Basic Vala Sample Code */ using GLib; public class Sample_create : Object { public void widgets() { } } public class Sample : Object { public void create_widgets () { } } produces 2 functions called sample_create_widgets and therefore the generated C code is invalid.
Confirming. There should be a Vala error message to catch the problem before running the C compiler and you should be able to specify an alternative cname in an attribute.
*** Bug 539489 has been marked as a duplicate of this bug. ***
*** Bug 549646 has been marked as a duplicate of this bug. ***
*** Bug 586484 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Confirming. There should be a Vala error message to catch the problem before > running the C compiler and you should be able to specify an alternative cname > in an attribute. Hi, shouldn't it be better to append '_<random guid>' to every symbols generated by vala?
We certainly can't generate random identifiers for public identifiers. They need to be stable and predictable (and memorable).
Created attachment 162268 [details] [review] Proposed patch for bug472259.
oops, I forgot the comment. This is a patch for the bug. It performs the check during the SymbolResolver step.
Review of attachment 162268 [details] [review]: Thanks for the patch. Actually the SymbolResolver has no knowledge of the C backend. Therefore that code should be somehow moved into the C code generator.
*** Bug 614916 has been marked as a duplicate of this bug. ***
I've read a few times that we expect GCC to be the backend for Vala. I read this today: 4.26 Dollar Signs in Identifier Names In GNU C, you may normally use dollar signs in identifier names. This is because many traditional C implementations allow such identifiers. However, dollar signs in identifiers are not supported on a few target machines, typically because the target assembler does not allow them. So... maybe we could use a dollar to join the classname to the method, instead of _ ? If it is likely to be supported on all vala-ish platforms... and maybe we could define symbol aliases for libraries so they don't HAVE to be troubled by the $ generally.
(In reply to comment #11) > I've read a few times that we expect GCC to be the backend for Vala. I don't know where you've read this but this is not true. There would be quite a few things we could simplify if we required GCC but valac doesn't require much more than C89. At least at some point people were using Vala with MSVC, Sun Studio, TinyCC, and LLVM, as far as I know.
Your Vala Code should follow: https://developer.gnome.org/gobject/stable/gtype-conventions.html In this case the class's name Sample_create should be invalidated. Then this bug should be translated to as an enhancement on code analysis and produce an warning at Code Generation phase. Changed to 1.2 milestone.
(In reply to Daniel Espinosa from comment #13) > Your Vala Code should follow: > > https://developer.gnome.org/gobject/stable/gtype-conventions.html > > In this case the class's name Sample_create should be invalidated. If you mean it should be SampleCreate instead of Sample_create, then that is not documented in the page you have linked to. The closest I can find in that document is "Use the object_method pattern for function names: to invoke the method named save on an instance of object type file, call file_save". That doesn't relate to what you are saying though. > Then this bug should be translated to as an enhancement on code analysis and > produce an warning at Code Generation phase. > > Changed to 1.2 milestone. Vala should have robust handling of identifier names. Identifiers are a fundamental concept and should be part of any 1.0 release to my mind. Also given the number of duplicates of this bug, four have been linked, then this is an important issue to others as well. I have changed the milestone to 1.0 for those reasons.
https://developer.gnome.org/gobject/stable/gtype-conventions.html Prefixed type names convention is not explicitly documented. No conventions like: * No [_] is allowed as a separator in type's names, so use MyObject instead of My_Object, in order to honor method's names convention. * Prefixed type's names are convenient to avoid type conflicts. If your library or program is called Viewer, your type's name should be ViewerObject Above is a non written convention followed by Vala. From above link: "Use prefixing to avoid namespace conflicts with other projects. If your library (or application) is named Viewer, prefix all your function names with viewer_. For example: viewer_object_method. " Most projects use type names prefixing. "Object" is an accepted choice for a type name. If "Viewer" is your library or program's name, using ViewerObject is a common choice. In the example above using SampleCreate and Sample.Create results in a namespace prefixing, so using Sample as a class name just ignores prefixing. Sample._create is equivalent to Sample_create, so using just Sample for another classes' name, can be considered a programming error, because an inconsistent prefixing policy in the class naming. All this should be documented in both GObject and Vala, in order to avoid that conflicts and help users to create consistent classes and method naming.
(In reply to Daniel Espinosa from comment #15) > https://developer.gnome.org/gobject/stable/gtype-conventions.html > > Prefixed type names convention is not explicitly documented. That was my point, you made a misleading reference. There is no need to re-state that, but thank you for acknowledging it. > All this should be documented in both GObject and Vala, in order to avoid > that conflicts and help users to create consistent classes and method naming. I don't think you can make this one disappear as a documentation bug. Personally I agree with this comment that states the goals of a 1.0 release clearly to my mind: https://bugzilla.gnome.org/show_bug.cgi?id=531428#c13 You should also read and absorb comments #1 and #6 of this bug. They provide some limiting scope for what is required. As far as a solution goes, I think Vala to C name translation could be done with CodeBaseModule.get_ccode_name () as part of the symbol resolver stage on the Vala AST to generate the cname and then check it is unique. Although CCodeAttribute.get_default_name () does look complex. See also https://bugzilla.gnome.org/show_bug.cgi?id=790239
*** Bug 694236 has been marked as a duplicate of this bug. ***
*** Bug 729255 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/1.