In the first example, Option B contained more information than Option A, to
the point where Option A would leave me head-scratching for a while. In the
newer example, I also find the order of Option B to be more intuitive.
On Sat, Dec 7, 2013 at 3:24 PM, Thiago Macieira
wrote:
> On sábado, 7 de
On sábado, 7 de dezembro de 2013 15:03:26, Chris Colbert wrote:
> Is there a line missing from Option A, just after the line for ?
This specific compiler did not output anything for this case.
That case was a misuse of a macro. Here's another example, where the problem
is inside the macro.
Opti
Is there a line missing from Option A, just after the line for ?
On Sat, Dec 7, 2013 at 2:53 PM, Thiago Macieira
wrote:
> Hi guys
>
> Just a quick poll: which order do you think is more intuitive?
>
> Option A:
> qobjectdefs.h:69:20: error: expected unqualified-id before ‘protected’
> # defin
Hi guys
Just a quick poll: which order do you think is more intuitive?
Option A:
qobjectdefs.h:69:20: error: expected unqualified-id before ‘protected’
# define signals protected
^
:1:6: note: in expansion of macro ‘signals’
Option B:
:1:6: error: expected unqualified-id
b
On sábado, 7 de dezembro de 2013 13:36:35, Kurt Pattyn wrote:
> "-Wsign-conversion"
> "-Wsign-promo"
> "-Wsign-compare"
Oh, man. These three are extremely annoying. I now remember why we don't like
unsigned types in our API..
On sábado, 7 de dezembro de 2013 13:38:20, Kurt Pattyn wrote:
> > I still have a pending change that compiles each and every public header
> > independently -Werror and defining the keywords.
> >
> >
> >
> > None of my builds with Clang or GCC have any warnings. There are a few
> > with ICC beca
I had the same issue recently. It was because my qtdeclarative module (and
maybe others) was not built on 'stable'. I corrected by ensuring all
submodules were checked out to 'stable' where possible, or 'master'
otherwise.
On Sat, Dec 7, 2013 at 11:15 AM, Nurmi J-P wrote:
> On 07 Dec 2013, at 1
On 07 Dec 2013, at 16:26, Kurt Pattyn wrote:
> The latest stable branch (dbac1e77f79ff99945cea41522f535132cacc692), fails to
> build.
> qtdeclarative/src/quick/items/qquicktextnode.cpp: smoothScalable is not
> defined on font engine
>
I'm not using the "stable sha1's" from the qt5 repo while
The latest stable branch (dbac1e77f79ff99945cea41522f535132cacc692), fails to
build.
qtdeclarative/src/quick/items/qquicktextnode.cpp: smoothScalable is not defined
on font engine
___
Development mailing list
Development@qt-project.org
http://lists.qt-
On 07 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:
> From: Thiago Macieira
> Subject: Re: [Development] [Request] Compiler warnings in Qt
> Date: 6 Dec 2013 18:15:47 GMT+1
> To: development@qt-project.org
>
>
> On sexta-feira, 6 de dezembro de 2013 13:41:34, Olivier Goffart wr
On 07 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:
> From: Thiago Macieira
> Subject: Re: [Development] [Request] Compiler warnings in Qt
> Date: 6 Dec 2013 18:16:20 GMT+1
> To: development@qt-project.org
>
>
> On sexta-feira, 6 de dezembro de 2013 11:16:20, Kurt Pattyn wrote:
On Friday 06 December 2013 09:15:47 Thiago Macieira wrote:
> On sexta-feira, 6 de dezembro de 2013 13:41:34, Olivier Goffart wrote:
> > There used to be a 'compilerwarnings' autotest that made sure there was no
> > warning in the headers (in a more strict ways that the warnings we check
> > while
12 matches
Mail list logo
