Hi,
On 08/21/2015 11:23 AM, Markus Trippelsdorf wrote:
On 2015.08.21 at 11:06 +0200, Paolo Carlini wrote:
... I'm testing the below. So far appears to work well for me.
Yes for me, too. Firefox now builds without any issues.
So emitting an error (like clang) is fine after all.
Excellent.
On 08/21/2015 05:06 AM, Paolo Carlini wrote:
if (DECL_NAME (decl)
MAIN_NAME_P (DECL_NAME (decl))
- CP_DECL_CONTEXT (decl) == global_namespace)
+ CP_DECL_CONTEXT (decl) == global_namespace
+ !at_function_scope_p ())
How about looking at the scope local variable
Hi,
On 08/21/2015 05:37 PM, Jason Merrill wrote:
On 08/21/2015 05:06 AM, Paolo Carlini wrote:
if (DECL_NAME (decl)
MAIN_NAME_P (DECL_NAME (decl))
- CP_DECL_CONTEXT (decl) == global_namespace)
+ CP_DECL_CONTEXT (decl) == global_namespace
+ !at_function_scope_p ())
On 08/21/2015 01:11 PM, Paolo Carlini wrote:
Ah nice. Simply checking:
scope == global_namespace
appears to work great. Shall I go with that if testing is fine?
Please.
Jason
On 2015.08.21 at 08:18 +0200, Markus Trippelsdorf wrote:
On 2015.08.19 at 21:46 +0200, Paolo Carlini wrote:
Hi,
submitter noticed that, in violation of [basic.start.main], we don't
reject as ill-formed the declaration of a 'main' variable in the global
namespace. Not a big deal IMHO,
On 2015.08.19 at 21:46 +0200, Paolo Carlini wrote:
Hi,
submitter noticed that, in violation of [basic.start.main], we don't
reject as ill-formed the declaration of a 'main' variable in the global
namespace. Not a big deal IMHO, but the below simple check works well
for me on
Hi,
On 08/21/2015 08:30 AM, Markus Trippelsdorf wrote:
On 2015.08.21 at 08:18 +0200, Markus Trippelsdorf wrote:
On 2015.08.19 at 21:46 +0200, Paolo Carlini wrote:
Hi,
submitter noticed that, in violation of [basic.start.main], we don't
reject as ill-formed the declaration of a 'main'
On 2015.08.21 at 11:06 +0200, Paolo Carlini wrote:
... I'm testing the below. So far appears to work well for me.
Yes for me, too. Firefox now builds without any issues.
So emitting an error (like clang) is fine after all.
Thanks.
--
Markus
... I'm testing the below. So far appears to work well for me.
Paolo.
///
Index: cp/decl.c
===
--- cp/decl.c (revision 227054)
+++ cp/decl.c (working copy)
@@ -8357,7 +8357,8 @@ grokvardecl (tree type,
if
Hi,
submitter noticed that, in violation of [basic.start.main], we don't
reject as ill-formed the declaration of a 'main' variable in the global
namespace. Not a big deal IMHO, but the below simple check works well
for me on x86_64-linux.
Thanks,
Paolo.
//
/cp
Hi,
On 08/19/2015 10:33 PM, Ville Voutilainen wrote:
On 19 August 2015 at 23:26, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi Ville,
On 08/19/2015 10:12 PM, Ville Voutilainen wrote:
submitter noticed that, in violation of [basic.start.main], we don't
reject
as ill-formed the declaration
On 19 August 2015 at 23:37, Paolo Carlini paolo.carl...@oracle.com wrote:
Ah, Ok, I didn't actually try to compile your snippet. Then I suspect you
mean c++/66606?!? Please double check if something is missing in Martin's
bug!
That looks fairly comprehensive to me, I don't think I have cases
On 19 August 2015 at 23:26, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi Ville,
On 08/19/2015 10:12 PM, Ville Voutilainen wrote:
submitter noticed that, in violation of [basic.start.main], we don't
reject
as ill-formed the declaration of a 'main' variable in the global
namespace.
Not
submitter noticed that, in violation of [basic.start.main], we don't reject
as ill-formed the declaration of a 'main' variable in the global namespace.
Not a big deal IMHO, but the below simple check works well for me on
x86_64-linux.
Just fyi, gcc accepts
decltype(main) x;
Hi Ville,
On 08/19/2015 10:12 PM, Ville Voutilainen wrote:
submitter noticed that, in violation of [basic.start.main], we don't reject
as ill-formed the declaration of a 'main' variable in the global namespace.
Not a big deal IMHO, but the below simple check works well for me on
x86_64-linux.
OK.
Jason
16 matches
Mail list logo