From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-368902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25002 invoked by alias); 27 Sep 2011 22:23:52 -0000
Received: (qmail 24989 invoked by uid 22791); 27 Sep 2011 22:23:51 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Sep 2011 22:23:37 +0000
From: "giecrilj at stegny dot 2a.pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/49152] Unhelpful diagnostic for iterator dereference
Date: Wed, 28 Sep 2011 00:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: giecrilj at stegny dot 2a.pl
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-49152-4-u39rWpg3yE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49152-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49152-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-09/txt/msg02079.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49152

--- Comment #8 from Christopher Yeleighton <giecrilj at stegny dot 2a.pl> 2=
011-09-27 22:23:34 UTC ---
> I agree that this would be an improvement, even without clang's selective
> typedef unwrapping. But I have some doubts such a patch will be accepted.=
 I was
> told in a couple of occasions that I cannot just remove the expression fr=
om the
> diagnostic and rely on the user to look up the source code location.

What follows is an expression regurgitated by g++ for your convenient perus=
al.=20
You might want to show it to the person who expresses such strong opinions.=
=20
Ask him gently to tell you what it means.

doit.cpp:290:129: error: no match for =E2=80=98operator<<=E2=80=99 in =E2=
=80=98std::cout <<
boost::range::equal_range [with ForwardRange =3D
boost::range_detail::transform_range<boost::value_factory<ls::file_rec<char=
>::as_char0>,
std::vector<ls::file_rec<char> > >, Value =3D int, typename
boost::range_iterator<const ForwardRange>::type =3D
boost::transform_iterator<boost::value_factory<ls::file_rec<char>::as_char0=
>,
__gnu_cxx::__normal_iterator<ls::file_rec<char>*,
std::vector<ls::file_rec<char> > >, boost::use_default,
boost::use_default>]((*(const
boost::range_detail::transform_range<boost::value_factory<ls::file_rec<char=
>::as_char0>,
std::vector<ls::file_rec<char> > >*)(& boost::range_detail::operator| [with
InputRng =3D std::vector<ls::file_rec<char> >, UnaryFunction =3D
boost::value_factory<ls::file_rec<char>::as_char0>]((* & lv_fr), (*(const
boost::range_detail::transform_holder<boost::value_factory<ls::file_rec<cha=
r>::as_char0>
>*)(&
boost::adaptors::{anonymous}::transformed.boost::range_detail::forwarder<Ho=
lder>::operator()
[with T =3D boost::value_factory<ls::file_rec<char>::as_char0>, Holder =3D
boost::range_detail::transform_holder]((boost::value_factory<ls::file_rec<c=
har>::as_char0>(),
boost::value_factory<ls::file_rec<char>::as_char0>()))))))), (*
&((int)a_n.std::basic_string<_CharT, _Traits, _Alloc>::operator[] [with _Ch=
arT
=3D char, _Traits =3D std::char_traits<char>, _Alloc =3D std::allocator<cha=
r>,
std::basic_string<_CharT, _Traits, _Alloc>::reference =3D char&,
std::basic_string<_CharT, _Traits, _Alloc>::size_type =3D long unsigned
int](0ul))))=E2=80=99