Is it possible that your clang is buggy? I'm also using clang with the
following cflags: -g3 -O2 -Wall -Wextra -Wshadow -Wno-type-limits
-Wpointer-arith -Wno-missing-field-initializers -Wstrict-prototypes
-fvisibility=hidden
Clang version: 3.7.1
Zero warnings.
Looking at the code, zero warnings is correct, because the result is used.
--
Tom.
On 10/03/16 06:48, Jean-Philippe André wrote:
> Oh and I forgot, those changes add ~60 warnings in EFL with clang:
>
> CC lib/evas/canvas/lib_evas_libevas_la-evas_object_line.lo
> /home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c:101:5:
> warning: expression result unused [-Wunused-value]
> ((Eo *) ( *&eo_obj =
> _eo_add_internal_start("/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c",
> 101, evas_line_class_get(), e, ((Eina_Bool)0)), *&eo_obj =
> _eo_add_end(*&eo_obj) ));
>
>
> On 10 March 2016 at 15:46, Jean-Philippe André <[email protected]> wrote:
>
>>
>>
>> On 10 March 2016 at 15:05, Carsten Haitzler <[email protected]> wrote:
>>
>>> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui <[email protected]>
>>> said:
>>>
>>>> On Wed, 09 Mar 2016 16:23:04 +0000
>>>> Tom Hacohen <[email protected]> wrote:
>>>>
>>>>> On 03/03/16 10:22, Tom Hacohen wrote:
>>>>>> On 01/03/16 09:05, Tom Hacohen wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> The Eo syntax is going to be changing once more, and this time, I
>>>>>>> really think/hope it'll be the last time. We plan on stabilizing
>>>>>>> Eo and all of the functions on top of it in the next few months,
>>>>>>> so that doesn't leave us much more time to change it again. :)
>>>>>>>
>>>>>>> These changes will remove the need for the eo_do family of
>>>>>>> functions. Functions will now look like normal C functions (which
>>>>>>> they are). There are many benefits to that, and we have many cool
>>>>>>> new ideas.
>>>>>>>
>>>>>>> For more info: https://phab.enlightenment.org/w/eo/
>>>>>>>
>>>>>>> I'm sending this email as an head's up, as I'll be starting to
>>>>>>> work on migrating to the new Eo syntax (and implementing it)
>>>>>>> today. Felipe and I have actually already started (needed to for
>>>>>>> the PoC), but I plan on pushing my changes to master soon.
>>>>>>>
>>>>>>> If you have any issues/suggestions/comments with the proposal,
>>>>>>> please let me know, either in pm, irc or just here.
>>>>>>>
>>>>>>
>>>>>> Changes are in! I still haven't migrated eo_add to the new syntax
>>>>>> (it uses a non portable gcc extension in the meanwhile), but
>>>>>> otherwise everything is in. Took me *much* less time than I thought
>>>>>> it would, so yay. :P
>>>>>>
>>>>>> I decided to push it now instead of letting it rest in my branch
>>>>>> for a while because literally every hour that passed introduced
>>>>>> more merge conflicts for me, so the benefits from stabilising it
>>>>>> more in my branch were diminished by the new conflicts and issues
>>>>>> that could arise.
>>>>>>
>>>>>> If you have an application that uses the Eo api, you can use my
>>>>>> script https://devs.enlightenment.org/~tasn/migrate_eo.py to
>>>>>> migrate your code. When using the script you should keep two things
>>>>>> in mind: 1. You are only allowed to run it *once* per source code,
>>>>>> because the changes to eo_add() would otherwise accumulate and your
>>>>>> code will be wrong. If you need to correct something you've done
>>>>>> wrong, reset the code to the previous state and run the script
>>>>>> again on the original code. 2. The migration script is not perfect.
>>>>>> In particular it can't deal with some corner cases like:
>>>>>> eo_do(obj, a_set(1),
>>>>>> /* b_set(2),
>>>>>> g_set(4), */
>>>>>> c_set(2));
>>>>>> Or abominations like:
>>>>>> eo_do(obj, if (a_get())
>>>>>> do_something());
>>>>>>
>>>>>> So please be aware of that and *manually* review your changes after
>>>>>> the script has run.
>>>>>>
>>>>>> If your code does have these cases, I recommend you either get rid
>>>>>> of them, or manually migrate that code before running the script
>>>>>> (remove the relevant eo_do).
>>>>>>
>>>>>> Follow the wiki page mentioned in the previous email for more
>>>>>> information about Eo and what else needs changing.
>>>>>>
>>>>>> Please let me know about any regressions (there shouldn't be any)
>>>>>> or any issues you may face.
>>>>>
>>>>> I'm now pushing my changes to eo_add. I'm pushing it now for the same
>>>>> reason I pushed the previous changes in.
>>>>>
>>>>> I created a new script that assumes the code has already been
>>>>> migrated with the previous (migrate_eo.py) script. This script is
>>>>> called migrate_eo_add.py and can be found at:
>>>>> https://devs.enlightenment.org/~tasn/migrate_eo_add.py
>>>>>
>>>>> When using the script you should keep two things in mind:
>>>>> 1. You are only allowed to run it *once* per source code, because the
>>>>> changes to eo_add() would otherwise accumulate and your code will be
>>>>> wrong. If you need to correct something you've done wrong, reset the
>>>>> code to the previous state and run the script again on the original
>>>>> code. 2. The migration script is not perfect. In particular it can't
>>>>> deal with cases like missing {} for if/for/while content so for
>>>>> example,
>>>>>
>>>>> if ()
>>>>> return eo_add(...)
>>>>>
>>>>> would break.
>>>>> 3. If you are fancy and use the same variable inside eo_add and
>>>>> outside, for example like:
>>>>> parent = eo_add(CLASS, parent);
>>>>>
>>>>> your code will break. I suggest you use a temporary variable.
>>>>>
>>>>> So please be aware of that and *manually* review your changes after
>>>>> the script has run.
>>>>>
>>>>> If your code does have these cases, I recommend you either get rid of
>>>>> them, or manually migrate that code before running the script (remove
>>>>> the relevant eo_do).
>>>>>
>>>>>
>>>>>
>>>>> Sorry, but C++ will break until the C++ guys fix it. I'm now in the
>>>>> process of migrating the rest of our applications. Hopefully this
>>>>> will be the last disruption of this sort.
>>>>>
>>>>
>>>> Sorry man but the new syntax is ugly. I still don't see why this change
>>> was
>>>> needed. Please enlighten me. It reminds me the wonderful eo_do_ret
>>> syntax :-)
>>>>
>>>> So yes Tom I vomit on your eo_add
>>>>
>>>>
>>>> BBEEEUUUUUUAAAAAHHHHH...
>>>>
>>>> %%%%%%
>>>> %%%% = =
>>>> %%C >
>>>> _)' _( .' ,
>>>> __/ |_/\ " *. o
>>>> /` \_\ \/ %`= '_ .
>>>> / ) \/| .^',*. ,
>>>> /' /- o/ - " % '_
>>>> /\_/ < = , ^ ~ .
>>>> )_o|----'| .` '
>>>> ___// (_ - (\ eo_add(&obj...
>>>> ///-( \' \\
>>>
>>> bwhahahahahha.
>>
>>
>>> the reason was eo add methods.
>>>
>>> obj = eo_add(..., text_set(obj, "x"), color_set(obj, 1, 2, 3, 4));
>>>
>>> because eo4 changes to pass obj into every method - that means obj has to
>>> be
>>> filled and defined with the RIGHT eo id before the extra text_set() is
>>> called
>>> because it passes it in, thus you have to pass a ptr to the eiod so it
>>> can be
>>> filled in first so it is correct for the following calls within the
>>> eo_add.
>>>
>>
>> I know you don't like it but I can see two solutions to that:
>> 1. a different macro for eo_add() that doesn't allow any function calls
>> before finalize (I believe it would be used quite often)
>> 2. use a tls to store the currently created obj and add a macro to get it
>> in those inlined function calls, eg.
>> obj = eo_add(CLASS, parent, do_something(eo_cur))
>>
>> wrt. 1. I wonder how the bindings will even be able to create objects and
>> call functions before finalize?
>>
>> Best regards,
>>
>> --
>> Jean-Philippe André
>>
>
>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
