[wwwdocs] Add feature-testing macros and std::is_final to gcc-5/changes.html

On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
>Note Ed's recent changes. Committed to CVS.

And fix a markup error that I expected xmllint to catch :-(

On 10/02/2014 06:14 AM, Jonathan Wakely wrote:
> On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
>> Note Ed's recent changes. Committed to CVS.
>
> And fix a markup error that I expected xmllint to catch :-(
Thank you! I tried to do this and couldn't for permissions.  I'm 
probably not doing it right.

Anyway, the real thing I wanted to suggest is we put a line for C-family 
about the availability of __has_include and __has_include_next.  We 
could mention clang has it.

Thanks,

Ed

On 02/10/14 10:09 -0400, Ed Smith-Rowland wrote:
>On 10/02/2014 06:14 AM, Jonathan Wakely wrote:
>>On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
>>>Note Ed's recent changes. Committed to CVS.
>>
>>And fix a markup error that I expected xmllint to catch :-(
>Thank you! I tried to do this and couldn't for permissions.  I'm 
>probably not doing it right.

If I remember my cvs-fu you need CVS_RHS=ssh and use
CVSROOT=:ext:$USER@gcc.gnu.org:/cvs/gcc (with your sourceware.org
username as $USER) and then it should work over SSH just like svn and
git.

>Anyway, the real thing I wanted to suggest is we put a line for 
>C-family about the availability of __has_include and 
>__has_include_next.  We could mention clang has it.

Good idea, I'm happy to commit a patch if you can prepare something.

On 10/02/2014 10:58 AM, Ed Smith-Rowland wrote:
> We've had a request from someone that we include SD-6 feature testing
> for gcc-4.9.
> It seems rather heavy for a backport but it might make maintainers of
> large C++ libraries happy ;-) and it might make sense as people migrate
> from 4.9 to 5.0 to see what we've added.

I'm open to that.

Jason

The library macros are safe and can't cause any issues, so I'm happy for them to go on the branch.

I can think of at least two that aren't implemented on the branch: <experimental/any> and the std::is_final trait (although I'd be OK with the trait going on the branch too).



----- Original Message -----
From: "Jason Merrill" <jason@redhat.com>
To: "Ed Smith-Rowland" <3dw4rd@verizon.net>, "Jonathan Wakely" <jwakely@redhat.com>
Cc: gcc-patches@gcc.gnu.org, "thiago macieira" <thiago.macieira@intel.com>
Sent: Thursday, 2 October, 2014 4:40:03 PM
Subject: Re: feature-testing macros for 4.9

On 10/02/2014 10:58 AM, Ed Smith-Rowland wrote:
> We've had a request from someone that we include SD-6 feature testing
> for gcc-4.9.
> It seems rather heavy for a backport but it might make maintainers of
> large C++ libraries happy ;-) and it might make sense as people migrate
> from 4.9 to 5.0 to see what we've added.

I'm open to that.

Jason

On Thursday 02 October 2014 11:42:35 Jonathan Wakely wrote:
> The library macros are safe and can't cause any issues, so I'm happy for
> them to go on the branch.
> 
> I can think of at least two that aren't implemented on the branch:
> <experimental/any> and the std::is_final trait (although I'd be OK with the
> trait going on the branch too).

I'd also appreciate that the core language macros be defined too in 4.9. The 
patch I had submitted was based on 4.9 and tried to be the least intrusive as 
possible.

On 10/02/2014 10:24 AM, Jonathan Wakely wrote:
> On 02/10/14 10:09 -0400, Ed Smith-Rowland wrote:
>> On 10/02/2014 06:14 AM, Jonathan Wakely wrote:
>>> On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
>>>> Note Ed's recent changes. Committed to CVS.
>>>
>>> And fix a markup error that I expected xmllint to catch :-(
>> Thank you! I tried to do this and couldn't for permissions.  I'm 
>> probably not doing it right.
>
> If I remember my cvs-fu you need CVS_RHS=ssh and use
> CVSROOT=:ext:$USER@gcc.gnu.org:/cvs/gcc (with your sourceware.org
> username as $USER) and then it should work over SSH just like svn and
> git.
>
>> Anyway, the real thing I wanted to suggest is we put a line for 
>> C-family about the availability of __has_include and 
>> __has_include_next.  We could mention clang has it.
>
> Good idea, I'm happy to commit a patch if you can prepare something.
>
>
OK, here is a patch for both using typename as a class key for template 
template parms and for __has_include, etc.
Are these too wordy?

Ed
Index: htdocs/gcc-5/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.14
diff -r1.14 changes.html
56a57,81
>     <li>New preprocessor constructs, <code>__has_include_next</code>
>         and <code>__has_include_next</code>, to test the availability of headers
>         have been added.<br/>
>         This demonstrates a way to include the header <code>&lt;optional&gt;</code>
>         only if it is available:<br/>
> <blockquote><pre>
> #ifdef __has_include
> #  if __has_include(&lt;optional&gt;)
> #    include &lt;optional&gt;
> #    define have_optional 1
> #  elif __has_include(&lt;experimental/optional&gt;)
> #    include &lt;experimental/optional&gt;
> #    define have_optional 1
> #    define experimental_optional
> #  else
> #    define have_optional 0
> #  endif
> #endif
> </pre></blockquote>
>         The header search paths for <code>__has_include_next</code>
>         and <code>__has_include_next</code> are equivalent to those
>         of the standard directive <code>#include</code>
>         and the extension <code>#include_next</code> respectively.
>     </li>
> 
88a114,117
>   <li>G++ now allows <code>typename</code> in a template template parameter.
>     <blockquote><pre>
>       template&lt;template&lt;typename&gt; <b>typename</b> X&gt; struct D; // OK
>     </pre></blockquote></li>

On 07/10/14 08:39 -0400, Ed Smith-Rowland wrote:
>OK, here is a patch for both using typename as a class key for 
>template template parms and for __has_include, etc.
>Are these too wordy?

They look OK to me, although you say "__has_include_next and
__has_include_next" in both places, the first should be just
__has_include.

I can make that change and commit it, thanks.