experimental testsuite patch

Hi

     Here is a patch to partially fix 2 string_view tests. It looks like 
we can't use 2 dg-options into the same source, one override the over, 
the dg-options directives have been merged into 1. I also update a 
script to make the experimental folder part of the folders to look for 
tests. I don't know if it was intentionally omitted because of the 
experimental aspect of what is tested, if so just tell me I won't apply 
this part.

     Remaining failures in string_view tests in debug mode are all 
coming from this kind of code:

       constexpr const _CharT&
       operator[](size_type __pos) const
       {
     _GLIBCXX_DEBUG_ASSERT(__pos <= this->_M_len);
     return *(this->_M_str + __pos);
       }

     In debug mode the _GLIBCXX_DEBUG_ASSERT is activated and the 
operator cannot be a constexpr anymore.  Maybe Ed can tell what should 
be done, remove the assertion or remove the constexpr (maybe only in 
debug mode ?) ?

2014-01-15  François Dumont <fdumont@gcc.gnu.org>

     * scripts/create_testsuite_files: Add testsuite/experimental in
     the list of folders to introspect for tests.
     * testsuite/experimental/string_view/element_access/wchar_t/2.cc:
     Merge dg-options directives into one.
     * testsuite/experimental/string_view/element_access/char/2.cc:
     Likewise. Remove invalid experimental namespace scope on
     string_view_type.

Tested under Linux x86_64 normal and debug modes.

François

On 15 January 2014 16:56, François Dumont wrote:
> Hi
>
>     Here is a patch to partially fix 2 string_view tests. It looks like we
> can't use 2 dg-options into the same source, one override the over, the
> dg-options directives have been merged into 1. I also update a script to
> make the experimental folder part of the folders to look for tests. I don't
> know if it was intentionally omitted because of the experimental aspect of
> what is tested, if so just tell me I won't apply this part.

I think it's OK.

>     Remaining failures in string_view tests in debug mode are all coming
> from this kind of code:
>
>       constexpr const _CharT&
>       operator[](size_type __pos) const
>       {
>     _GLIBCXX_DEBUG_ASSERT(__pos <= this->_M_len);
>     return *(this->_M_str + __pos);
>       }
>
>     In debug mode the _GLIBCXX_DEBUG_ASSERT is activated and the operator
> cannot be a constexpr anymore.  Maybe Ed can tell what should be done,
> remove the assertion or remove the constexpr (maybe only in debug mode ?) ?

I think we decided we want functions to be constexpr in debug mode if
they are constexpr in normal mode.

I think std::array has solved the same problem without losing the
constexpr qualifier.

> 2014-01-15  François Dumont <fdumont@gcc.gnu.org>
>
>     * scripts/create_testsuite_files: Add testsuite/experimental in
>     the list of folders to introspect for tests.

s/introspect/inspect/

The patch is OK with that change, thanks.,

On 01/15/2014 06:17 PM, Jonathan Wakely wrote:
> I think we decided we want functions to be constexpr in debug mode if
> they are constexpr in normal mode.
>
> I think std::array has solved the same problem without losing the
> constexpr qualifier.
Yes, I think the only complete solution we know of is that kind of 
strategy. But IMO it could wait, for the time being we could just 
comment out the checks and add comments about that (make sure first that 
the various make check* are clean as we are approaching the release of 
4.9.0)

Paolo.

On 15 January 2014 17:22, Paolo Carlini wrote:
> On 01/15/2014 06:17 PM, Jonathan Wakely wrote:
>>
>> I think we decided we want functions to be constexpr in debug mode if
>> they are constexpr in normal mode.
>>
>> I think std::array has solved the same problem without losing the
>> constexpr qualifier.
>
> Yes, I think the only complete solution we know of is that kind of strategy.
> But IMO it could wait, for the time being we could just comment out the
> checks and add comments about that (make sure first that the various make
> check* are clean as we are approaching the release of 4.9.0)

Yes, that would be the safest option. The assertions are not essential.