[C++] Grammar fix in pt.c comments.

* pt.c: Grammar fix in comments ("it's" to "its").

---
 gcc/cp/pt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Thank you for this patch, Adam.

Adam Butcher <adam@jessamine.co.uk> a écrit:

> 	* pt.c: Grammar fix in comments ("it's" to "its").

FWIW, this change seems to fall under the obvious rule and thus, ought
to be committed.

>
> ---
>  gcc/cp/pt.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index ce899ef..78b7a97 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
>  	  tree decl_arg_types;
>  
>  	  /* This is an ordinary member function.  However, since
> -	     we're here, we can assume it's enclosing class is a
> +	     we're here, we can assume its enclosing class is a
>  	     template class.  For example,
>  
>  	       template <typename T> struct S { void f(); };
> @@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree parms, bool is_primary,
>  	  || DECL_INITIALIZED_IN_CLASS_P (decl)))
>      /* We already checked these parameters when the template was
>         declared, so there's no need to do it again now.  This function
> -       was defined in class scope, but we're processing it's body now
> +       was defined in class scope, but we're processing its body now
>         that the class is complete.  */
>      return true;
>  
> @@ -7555,7 +7555,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree in_decl, tree context,
>  	the one of #0.
>  
>  	When we encounter #1, we want to store the partial instantiation
> -	of M (template<class T> S<int>::M<T>) in it's CLASSTYPE_TI_TEMPLATE.
> +	of M (template<class T> S<int>::M<T>) in its CLASSTYPE_TI_TEMPLATE.
>  
>  	For all cases other than this "explicit specialization of member of a
>  	class template", we just want to store the most general template into

On 08/12/2013 09:06 AM, Dodji Seketeli wrote:
> FWIW, this change seems to fall under the obvious rule and thus, ought
> to be committed.

Agreed.  But I don't see Adam's name in MAINTAINERS; do you still need 
to get set up for write after approval?

Jason

On 12.08.2013 16:33, Jason Merrill wrote:
> On 08/12/2013 09:06 AM, Dodji Seketeli wrote:
>> FWIW, this change seems to fall under the obvious rule and thus, 
>> ought
>> to be committed.
>
> Agreed.  But I don't see Adam's name in MAINTAINERS; do you still
> need to get set up for write after approval?
>
Yes, I must confess up until now I hadn't considered it.  I've just 
been submitting patches from a clone of http://gcc.gnu.org/git/gcc.git.  
Are you happy to approve this?  If so I'll set up a sourceware account 
at http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working 
with a git-svn clone of the main repo using svn+ssh.

Cheers,
Adam

On 08/12/2013 04:52 PM, Adam Butcher wrote:
> Yes, I must confess up until now I hadn't considered it.  I've just been
> submitting patches from a clone of http://gcc.gnu.org/git/gcc.git. Are
> you happy to approve this?

Yes.

> If so I'll set up a sourceware account at
> http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working with
> a git-svn clone of the main repo using svn+ssh.

git svn clone takes forever on the gcc repo; much better to connect 
git-svn to your existing repository.

http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29

Jason

On 12.08.2013 22:03, Jason Merrill wrote:
> On 08/12/2013 04:52 PM, Adam Butcher wrote:
>> Yes, I must confess up until now I hadn't considered it.  I've just 
>> been
>> submitting patches from a clone of http://gcc.gnu.org/git/gcc.git. 
>> Are
>> you happy to approve this?
>
> Yes.
>
Cheers.  Submitted.

>> If so I'll set up a sourceware account at
>> http://sourceware.org/cgi-bin/pdw/ps_form.cgi and switch to working 
>> with
>> a git-svn clone of the main repo using svn+ssh.
>
> git svn clone takes forever on the gcc repo; much better to connect
> git-svn to your existing repository.
>
> http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29
>
I was intending to git-svn fetch only 'trunk' from a few thousand 
revisions back from HEAD, not the whole repo (my response did not make 
this clear).  I had not seen that wiki page before though.  Useful.

Thanks,
Adam