vala issueshttps://gitlab.gnome.org/GNOME/vala/-/issues2024-02-24T21:30:23Zhttps://gitlab.gnome.org/GNOME/vala/-/issues/1499Deprecate "dynamic" keyword2024-02-24T21:30:23ZLorenz WildbergDeprecate "dynamic" keywordAs far as I could see the `dynamic` keyword is used in a couple of places:
- for very old DBus support, which nobody uses anymore
- for accessing properties and signals of gobjects "dynamically"
I wouldn't recommend the second use case ...As far as I could see the `dynamic` keyword is used in a couple of places:
- for very old DBus support, which nobody uses anymore
- for accessing properties and signals of gobjects "dynamically"
I wouldn't recommend the second use case either anymore, as 1. it has bugs and 2. It is not at all in line with the usual Vala programming concepts. It only makes working with some libraries like gstreamer more convenient. But its at the same time not much more difficult to use `GLib.Object.s/get()` and `GLib.Signal.connect()` and doing it manually etc...https://gitlab.gnome.org/GNOME/vala/-/issues/1181GObject property not initialized when enum default value is nonzero2022-05-11T05:05:23ZPrinceton FerroGObject property not initialized when enum default value is nonzeroIf a GObject property is of an enum type with a non-zero default value, then the property is not initialized to that value.
Example:
```vala
[CCode (default_value = "INSERT_TEXT_FORMAT_INSERT_TEXT")]
enum InsertTextFormat {
INSERT_T...If a GObject property is of an enum type with a non-zero default value, then the property is not initialized to that value.
Example:
```vala
[CCode (default_value = "INSERT_TEXT_FORMAT_INSERT_TEXT")]
enum InsertTextFormat {
INSERT_TEXT = 1,
SNIPPET = 2
}
class CompletionItem : Object {
public InsertTextFormat insert_text_format { get; set; }
}
void main () {
var item = new CompletionItem ();
print ("item.insert_text_format = %s\n", item.insert_text_format.to_string ());
}
```
```
% vala enum-default-nonzero.vala
item.insert_text_format = (null)
```0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1142GLib.Object (...) use wrong name when cname is defined2023-11-30T15:05:27ZGustavo MarquesGLib.Object (...) use wrong name when cname is definedwhen using `[CCode (cname="")]` on a property in vala, if you use the `Object (...)` constructor it's use the original name instead of the defined cname, for example:
```vala
public class TestClass : Object {
[CCode (cname="bar")]
...when using `[CCode (cname="")]` on a property in vala, if you use the `Object (...)` constructor it's use the original name instead of the defined cname, for example:
```vala
public class TestClass : Object {
[CCode (cname="bar")]
public string foo { get; set; }
public TestClass (string foo) {
Object (foo: foo);
}
public TestClass.empty () {
}
}
public void main () {
// this throw a critical error: object has no property named "foo"
var test1 = new TestClass ("is bar?");
// but this work
var test2 = new TestClass.empty () {
foo = "is bar?"
};
// and this too
TestClass test3 = (TestClass) Object.new (typeof (TestClass), bar: "is this bar?");
print ("test1 = %s\n", test1.foo); // test1 = (null)
print ("test2 = %s\n", test2.foo); // test2 = is bar?
print ("test3 = %s\n", test3.foo); // test3 = is this bar?
}
```
if i change the method to `Object (bar: foo);` valac throw a error
```
cname-test.vala:6.17-6.24: error: Property `bar' not found in `TestClass'
Object (bar: foo);
^^^^^^^^
Compilation failed: 1 error(s), 0 warning(s)
```0.58https://gitlab.gnome.org/GNOME/vala/-/issues/703Use --target-glib or check for gobject-2.0 in --pkg list instead of using --p...2023-12-03T22:03:46ZAl ThomasUse --target-glib or check for gobject-2.0 in --pkg list instead of using --profile in the command line interfaceLooking through some of the recent commits that are making really good progress in allowing Vala to compile without GLib, I notice a lot of the code uses the idiom of `if (context.profile == Profile.GOBJECT) {}`. This made made me think ...Looking through some of the recent commits that are making really good progress in allowing Vala to compile without GLib, I notice a lot of the code uses the idiom of `if (context.profile == Profile.GOBJECT) {}`. This made made me think of the following user interface:
`valac my_program.vala`
would compile as we think of as normal at present. So with all the GLib types.
`valac my_program.vala --nostdpkg --pkg basic-types-libc`
would compile for 'standard' C.
`valac my_program.vala --nostdpkg --pkg glib-2.0 --pkg gobject-2.0 --target-glib 2.40`
would be the equivalent of `valac my_program.vala`.
`--target-glib` would be the switch to activate the GOBJECT code in the compiler.
Without it Vala would target standard C. The problem with POSIX as a profile is it is a superset of the standard C library and there are platforms that people may want to target, like Windows and microcontrollers, that are not POSIX compliant.
I understand Meson may pass the --nostdpkg switch by default. In that case it may be better to have the Vala compiler check the package list passed and if it contains 'gobject-2.0' to enable the GOBJECT code generation.https://gitlab.gnome.org/GNOME/vala/-/issues/626Vala doesn't ensure the array passed to gtk_application_set_accels_for_action...2023-01-19T12:47:41ZBugzillaVala doesn't ensure the array passed to gtk_application_set_accels_for_action is null terminated## Submitted by Greg V
**[Link to original bug (#794731)](https://bugzilla.gnome.org/show_bug.cgi?id=794731)**
## Description
A common (at least in the elementary OS world) idiom for setting GTK accelerators seems to be using a Gee....## Submitted by Greg V
**[Link to original bug (#794731)](https://bugzilla.gnome.org/show_bug.cgi?id=794731)**
## Description
A common (at least in the elementary OS world) idiom for setting GTK accelerators seems to be using a Gee.HashMultiMap's to_array like this:
https://github.com/Alecaddd/sequeler/blob/03b81b482567fdfc39aed460ef89ff647e4adcf9/src/Services/ActionManager.vala#L36-L69
The GTK vapi marks that argument as null terminated:
public void set_accels_for_action (string detailed_action_name, [CCode (array_length = false, array_null_terminated = true)] string[] accels);
But the generated C code does not make it null terminated:
https://github.com/Alecaddd/sequeler/issues/96#issuecomment-375301139
So GTK starts reading garbage, which results in funny messages like
(Sequeler:50044): Gtk-WARNING **: 16:01:05.864: Unable to parse accelerator '\u0008\x8dn\u000b\u0008': ignored request to install 501 accelerators
(501 accelerators!) and much worse, SEGFAULTS!
(Apart from Sequeler, this happens in Geary when clicking "reply".)
I'm not sure where exactly should this be fixed — should Vala codegen ensure null-termination when passing to an array_null_terminated argument? Should libgee null-terminate in to_array? Should consumers construct new arrays instead of this (rather silly IMO) multimap trick?
And I'm extremely not sure how this wasn't discovered on Linux?! Was some unintended magic making them null terminated?
Version: 0.40.x1.0https://gitlab.gnome.org/GNOME/vala/-/issues/59064bit-portability-issues detected2020-03-23T09:27:51ZBugzilla64bit-portability-issues detected## Submitted by Bjørn Lie `@bjorn.lie`
**[Link to original bug (#784927)](https://bugzilla.gnome.org/show_bug.cgi?id=784927)**
## Description
When building new 0.37.1 unstable release, our post build checker complains about 64bit-po...## Submitted by Bjørn Lie `@bjorn.lie`
**[Link to original bug (#784927)](https://bugzilla.gnome.org/show_bug.cgi?id=784927)**
## Description
When building new 0.37.1 unstable release, our post build checker complains about 64bit-portability-issues in the following files:
```
[ 63s] E: vala 64bit-portability-issue content/embedded.c:613, 616
[ 63s] E: vala 64bit-portability-issue content/paragraph.c:416, 419
[ 63s] E: vala 64bit-portability-issue content/sourcecode.c:1588
[ 63s] E: vala 64bit-portability-issue content/tablecell.c:485, 488
```
Version: 0.41.x1.0https://gitlab.gnome.org/GNOME/vala/-/issues/581Ownership transfer of implicit GLib.Value/Variant transformation in property-...2018-05-22T15:47:26ZBugzillaOwnership transfer of implicit GLib.Value/Variant transformation in property-getters is not recognized## Submitted by Yannick Inizan `@BZHDeveloper`
**[Link to original bug (#780522)](https://bugzilla.gnome.org/show_bug.cgi?id=780522)**
## Description
Created attachment 348689
test case
with GLib.Value as GObject property, Vala gen...## Submitted by Yannick Inizan `@BZHDeveloper`
**[Link to original bug (#780522)](https://bugzilla.gnome.org/show_bug.cgi?id=780522)**
## Description
Created attachment 348689
test case
with GLib.Value as GObject property, Vala generates two GValue and returns wrong value (the initialized GValue isn't returned)
~~**Attachment 348689**~~, "test case":
[test.vala](/uploads/5861145204292e41f7764fc35e4a0abe/test.vala)
Version: 0.36.x
### See also
* [Bug 623543](https://bugzilla.gnome.org/show_bug.cgi?id=623543)
* [Bug 710882](https://bugzilla.gnome.org/show_bug.cgi?id=710882)https://gitlab.gnome.org/GNOME/vala/-/issues/560Vala does not warn about reusage of identifier "type" in GObject constructor2019-10-01T15:53:13ZBugzillaVala does not warn about reusage of identifier "type" in GObject constructor## Submitted by luk..@..bi.net
**[Link to original bug (#772995)](https://bugzilla.gnome.org/show_bug.cgi?id=772995)**
## Description
Code to reproduce:
```vala
class Foo : Object {
construct {
string type;
...## Submitted by luk..@..bi.net
**[Link to original bug (#772995)](https://bugzilla.gnome.org/show_bug.cgi?id=772995)**
## Description
Code to reproduce:
```vala
class Foo : Object {
construct {
string type;
}
}
void main () {}
```
Vala does not tell me not to use the variable "type". Instead g++ gives me the error
```
/home/lukas/tmp/type.vala.c:61:9: error: ‘type’ redeclared as different kind of symbol
gchar* type = NULL;
^
```
Which makes sense as "type" is first defined as "GType type" in the function signature:
```c
static GObject * foo_constructor (GType type, [...]
```
Cheers
### See also
* [Bug 472259](https://bugzilla.gnome.org/show_bug.cgi?id=472259)https://gitlab.gnome.org/GNOME/vala/-/issues/463Object-type construct properties overwrite their default with null2018-05-22T15:13:28ZBugzillaObject-type construct properties overwrite their default with null## Submitted by d.f..@..web.de
**[Link to original bug (#734013)](https://bugzilla.gnome.org/show_bug.cgi?id=734013)**
## Description
Created attachment 282115
An example for an overwritten default value
The attached file shows a c...## Submitted by d.f..@..web.de
**[Link to original bug (#734013)](https://bugzilla.gnome.org/show_bug.cgi?id=734013)**
## Description
Created attachment 282115
An example for an overwritten default value
The attached file shows a class that has a construct-only property of type Object. Whenever the construct block of the property is called, it just outputs its value. By default the property shall be assigned some newly created Object.
Running the program first outputs some address, indicating that the default indeed was set. But after that it outputs "(nil)" indicating that the property was again assigned, now to a null value. Would the property be stored, as an automatic property would do, this would overwrite it.
This also happens with "set construct" blocks, but not with "set" blocks. They are called just once, as it should be expected from construct blocks also.
**Attachment 282115**, "An example for an overwritten default value":
[construct-property.vala](/uploads/0e9bdc4eb9fb97da1db812587bfb0b19/construct-property.vala)https://gitlab.gnome.org/GNOME/vala/-/issues/462The diamond inheritance prohibits overloading2018-11-29T15:16:41ZBugzillaThe diamond inheritance prohibits overloading## Submitted by Maciej Marcin Piechotka `@mpiechotka`
**[Link to original bug (#733865)](https://bugzilla.gnome.org/show_bug.cgi?id=733865)**
## Description
Created attachment 281869
Vala example
If class A is subclass of B and A, ...## Submitted by Maciej Marcin Piechotka `@mpiechotka`
**[Link to original bug (#733865)](https://bugzilla.gnome.org/show_bug.cgi?id=733865)**
## Description
Created attachment 281869
Vala example
If class A is subclass of B and A, B implements I with method f, f cannot be overridden in subclass of C. It's possible to some extend workaround it in Vala by explicit method implementation (see attached code) but not for properties
Ideally it would follow the C# convention:
- If B contains the explicit implementation of f then call goes to explicit override as in C#
- If B does not contain it the explicit override call is either as in workaround (+ for speed) or just redirecting to correct method in parent class.
**Attachment 281869**, "Vala example":
[test-iface.vala](/uploads/969c5ddb687aab63acbf69c9a2062689/test-iface.vala)
Version: 0.25.xhttps://gitlab.gnome.org/GNOME/vala/-/issues/455Support renamed signals and properties2021-03-09T18:41:49ZBugzillaSupport renamed signals and properties## Submitted by Evan Nemerson
**[Link to original bug (#731547)](https://bugzilla.gnome.org/show_bug.cgi?id=731547)**
## Description
When we have a signal which conflicts with a property, such as DBusConnection.closed in GIO, we cur...## Submitted by Evan Nemerson
**[Link to original bug (#731547)](https://bugzilla.gnome.org/show_bug.cgi?id=731547)**
## Description
When we have a signal which conflicts with a property, such as DBusConnection.closed in GIO, we currently have to choose one because renaming either will result in incorrect C being generated. AFAIK there is no annotation for property or signal names.
### Blocking
* [Bug 684358](https://bugzilla.gnome.org/show_bug.cgi?id=684358)1.0https://gitlab.gnome.org/GNOME/vala/-/issues/426Use of GLib.return_if_fail in construct {} produces invalid code2018-05-22T15:03:08ZBugzillaUse of GLib.return_if_fail in construct {} produces invalid code## Submitted by Stef Walter
**[Link to original bug (#722090)](https://bugzilla.gnome.org/show_bug.cgi?id=722090)**
## Description
The construct { } syntax in vala does not have a return value. However when using GLib.return_if_fail...## Submitted by Stef Walter
**[Link to original bug (#722090)](https://bugzilla.gnome.org/show_bug.cgi?id=722090)**
## Description
The construct { } syntax in vala does not have a return value. However when using GLib.return_if_fail within a construct { } section, the resulting code is placed in an xxx_constructor() function which *does* have a return value.
Therefore you get a "Non-void function should return a value" problem.
Will attach a test case.
### Blocking
* [Bug 722023](https://bugzilla.gnome.org/show_bug.cgi?id=722023)https://gitlab.gnome.org/GNOME/vala/-/issues/391Use the offsets for computing the private data offsets2018-05-22T14:51:41ZBugzillaUse the offsets for computing the private data offsets## Submitted by Emmanuele Bassi `@ebassi`
**[Link to original bug (#703705)](https://bugzilla.gnome.org/show_bug.cgi?id=703705)**
## Description
GLib 2.38 changed the in-memory layout of instance and private data:
https://blogs.gno...## Submitted by Emmanuele Bassi `@ebassi`
**[Link to original bug (#703705)](https://bugzilla.gnome.org/show_bug.cgi?id=703705)**
## Description
GLib 2.38 changed the in-memory layout of instance and private data:
https://blogs.gnome.org/ebassi/2013/06/21/the-king-is-dead/
and introduces new API and macros to deal with this that make private data pointers obsolete.
Vala should switch to this new offset-based access, so that newly added API that relies on offsets (like the GTK template children API) can use it.1.0https://gitlab.gnome.org/GNOME/vala/-/issues/384Interfaces ignore default values of properties2021-03-06T21:01:11ZBugzillaInterfaces ignore default values of properties## Submitted by Eric Gregory
**[Link to original bug (#702774)](https://bugzilla.gnome.org/show_bug.cgi?id=702774)**
## Description
Let's say you have an interface that defines an abstract property with a default value:
```vala
pub...## Submitted by Eric Gregory
**[Link to original bug (#702774)](https://bugzilla.gnome.org/show_bug.cgi?id=702774)**
## Description
Let's say you have an interface that defines an abstract property with a default value:
```vala
public interface Example : Object {
protected abstract Gee.List<string> list { get; set; default = new Gee.ArrayList<string>(); }
}
```
Now you implement that interface as follows:
```vala
public class ExampleImplementation : Object, Example {
protected Gee.List<string> list { get; set; }
}
```
This will compile with no warnings/errors. However, if you try to read from list inside ExampleImplementation, it's null -- the default value defined in the interface is never actually assigned.
As a workaround, you have to re-define the default value in the implementation:
```vala
public class ExampleImplementation2 : Object, Example {
protected Gee.List<string> list { get; set; default = new Gee.ArrayList<string>(); }
}
```
A complete example is attached.
(Note that this may or may not be the same bug as #692674, I can't tell based on its description.)
```vala
public interface Example : Object {
protected abstract Gee.List<string> list { get; set; default = new Gee.ArrayList<string>(); }
public void is_list_null() {
print("Is the list property null? %s\n", list == null ? "YES" : "NO");
}
}
public class ExampleImplementation : Object, Example {
protected Gee.List<string> list { get; set; }
}
public class ExampleImplementation2 : Object, Example {
protected Gee.List<string> list { get; set; default = new Gee.ArrayList<string>(); }
}
void main() {
ExampleImplementation example1 = new ExampleImplementation();
ExampleImplementation2 example2 = new ExampleImplementation2();
example1.is_list_null();
example2.is_list_null();
return;
}
```
Version: 0.20.x1.0https://gitlab.gnome.org/GNOME/vala/-/issues/234First construction(g_object_new) might depend on if statement2018-05-22T14:10:15ZBugzillaFirst construction(g_object_new) might depend on if statement## Submitted by Tal
**[Link to original bug (#660049)](https://bugzilla.gnome.org/show_bug.cgi?id=660049)**
## Description
Created attachment 197422
All in one(user_config.vala, user_config.c.before, user_config.c.after)
When a con...## Submitted by Tal
**[Link to original bug (#660049)](https://bugzilla.gnome.org/show_bug.cgi?id=660049)**
## Description
Created attachment 197422
All in one(user_config.vala, user_config.c.before, user_config.c.after)
When a construct method is written in Vala, Vala won't always call directly to g_object_new () . This is when another construction method is called, and before changing any fields.
Now what would happen if the construction call is inside "if"?
Take a look at this code:
internal UserConfig.from_path (string conf_path, UserConfig? default_conf = null) {
//Cloning default if passed
// Posible fix, but it's failed(self is null)
//_use_player_select_popup = false;
if (default_conf == null)
// Another posible fix, but it's failed(multiply constructors - even when inside if)
//this ();// (Please assume it's exist)
report_trace ("It's so null!");
else {
report_trace ("It's not null!");
this.from_another (default_conf);// This is a clone constructor
}
...
}
You can see the problem in the c files when compiling it.
I compile it for you(as attachment) in valac 0.12, user_config.c.before(this code) and user_config.c.after(when commenting "this.from_another (default_conf);").
As you can see, I thought about two possible fixes, but doesn't help. Note that those are also shell considered as bug:
In the first possible fix, a field is being set before construction call, but it's should be valid because construction is depended on if statement.
In the second possible fix, it also fails because of multiply constructors error, even when each one is in another if block. It shouldn't be error.
3 bugs eventually. The only fix without changing valac, is not to use constructors, but static methods. I hope you won't choose these last exit, because it's possible to do it in C.
Thanks,
Tal
**Attachment 197422**, "All in one(user_config.vala, user_config.c.before, user_config.c.after)":
[user_config.tar.bz2](/uploads/c47067624044f3d88f229c9903e152c4/user_config.tar.bz2)
Version: 0.12.xhttps://gitlab.gnome.org/GNOME/vala/-/issues/222Vala does not take into account order of interfaces2019-11-12T07:41:41ZBugzillaVala does not take into account order of interfaces## Submitted by Maciej Marcin Piechotka `@mpiechotka`
**[Link to original bug (#656204)](https://bugzilla.gnome.org/show_bug.cgi?id=656204)**
## Description
If the Iterable requires Traversable such code would fail:
internal class ...## Submitted by Maciej Marcin Piechotka `@mpiechotka`
**[Link to original bug (#656204)](https://bugzilla.gnome.org/show_bug.cgi?id=656204)**
## Description
If the Iterable requires Traversable such code would fail:
internal class Gee.ReadOnlyCollection`<G>` : Object, Iterable`<G>`, Traversable`<G>`, Collection`<G>` {
As:
GLib-GObject-WARNING **: cannot add interface type `GeeIterable' to type `GeeReadOnlyCollection' which does not conform to prerequisite `GeeTraversable'
FAIL
Fixes:
1. Require correct order
2. Impose correct order internally1.0https://gitlab.gnome.org/GNOME/vala/-/issues/213Properties with internal setters still marked as writeable2018-05-22T14:05:16ZBugzillaProperties with internal setters still marked as writeable## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#653909)](https://bugzilla.gnome.org/show_bug.cgi?id=653909)**
## Description
With (master, 69be997725ce6d9f3bed80bd0aae3532a4023ee2), if I declare a property:
...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#653909)](https://bugzilla.gnome.org/show_bug.cgi?id=653909)**
## Description
With (master, 69be997725ce6d9f3bed80bd0aae3532a4023ee2), if I declare a property:
public Object my_property { get; internal set; }
the generated C code still marks the GObject property as writeable. This is not what I expected.
The setter C function for the property is correctly not exported outside the project, and all call sites which set the property correctly call this setter; so marking the property as read-only should be fine.
Version: 0.13.xhttps://gitlab.gnome.org/GNOME/vala/-/issues/181defining quarks2018-05-22T13:58:18ZBugzilladefining quarks## Submitted by Allison (desrt)
**[Link to original bug (#644877)](https://bugzilla.gnome.org/show_bug.cgi?id=644877)**
## Description
It would be nice if you could write
namespace MyProject {
public const Quark MAGIC = "magic"...## Submitted by Allison (desrt)
**[Link to original bug (#644877)](https://bugzilla.gnome.org/show_bug.cgi?id=644877)**
## Description
It would be nice if you could write
namespace MyProject {
public const Quark MAGIC = "magic";
}
to get:
#define MY_PROJECT_MAGIC my_project_get_magic_quark();
and:
GQuark
my_project_get_magic_quark (void) {
static GQuark q;
if (!q)
q = g_quark_from_static_string ("magic");
return q;
}
Although my use case requires control over the precise string value of the quark, it would also be possibly nice to have something like this:
namespace MyProject {
public const Quark MAGIC;
}
as equivalent to
public const Quark MAGIC = "__ MyProject.MAGIC quark __";
or some other properly-namespaced gunk.
Version: 0.11.xhttps://gitlab.gnome.org/GNOME/vala/-/issues/119In interfaces virtual properties are not hooked up in the generated c code2020-04-15T09:53:38ZBugzillaIn interfaces virtual properties are not hooked up in the generated c code## Submitted by Aaron Andersen
**[Link to original bug (#624101)](https://bugzilla.gnome.org/show_bug.cgi?id=624101)**
## Description
If you have a virtual property in an interface the function implementation is not hooked up in the...## Submitted by Aaron Andersen
**[Link to original bug (#624101)](https://bugzilla.gnome.org/show_bug.cgi?id=624101)**
## Description
If you have a virtual property in an interface the function implementation is not hooked up in the iface_name_base_init function (virtual methods are, though).
Version: 0.9.xhttps://gitlab.gnome.org/GNOME/vala/-/issues/112Allow [CCode (has_construct_function = false)] to be used for non-bindings2020-04-14T17:56:47ZBugzillaAllow [CCode (has_construct_function = false)] to be used for non-bindings## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#622506)](https://bugzilla.gnome.org/show_bug.cgi?id=622506)**
## Description
As discussed on IRC, it would be nice if `[CCode (has_construct_function = false)]` ...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#622506)](https://bugzilla.gnome.org/show_bug.cgi?id=622506)**
## Description
As discussed on IRC, it would be nice if `[CCode (has_construct_function = false)]` could be used in normal Vala code to stop Vala generating `*_construct()` functions for objects. This would allow the C API of Vala libraries to be neatened up (at the cost of making the objects potentially inextensible).