gccrs: fix a compiler crash when path expression contains nothing

[liushuyu]

gcc/rust/ChangeLog:

* ast/rust-path.h: allows error nodes to specify the source
location, so that it could be used in diagnostics later.
* parse/rust-parse-impl.h: creates the PathInExpression error node
with source location and prints proper diagnostics if the path
is empty.

gcc/testsuite/ChangeLog:

* rust/compile/paamayim-nekudotayim.rs: add a test for testing
proper error recovery logic when there is no path names.

[powerboat9]

This should probably be handled by the parser, rather than the type checker, but good catch

[liushuyu]

This should probably be handled by the parser, rather than the type checker, but good catch

I want to handle this in the parser, but there seems to be a curious comment in the parser code (https://github.com/Rust-GCC/gccrs/pull/3286/files#diff-0ec0ef9112d5a4a50636e9fde592f348f936f51b4139796976c7ad1608f935f8R6716-R6717) that states:

      // skip after somewhere?
      // don't necessarily throw error but yeah

[powerboat9]

Yeah, that's a bit odd. It looks like that comment was introduced by a2ea9f7e7027a9945744f5f7c126a0618a30c334 (at that point in file gcc/rust/test3/parse/rust-parse.cc) and it looks like according to https://doc.rust-lang.org/reference/paths.html#paths-in-expressions paths must have at least one segment. I'd think the comment could be removed -- @philberty @CohenArthur?

[CohenArthur]

I agree with @powerboat9. I think this case should be handled in the parser, this is how rustc seems to do it at least. so I'm happy with removing the comment and handling it in the parser @liushuyu. Once this is done I think this PR is ready to go 👍

[CohenArthur]

I think we need for #3295 to go through or this PR will also fail if it gets rebased. but I'm happy to merge it

[CohenArthur]

Suggested change

	{
	rust_error_at (path.get_locus (), "expected identifier");
	}
	rust_error_at (path.get_locus (), "expected identifier");

small formatting nit :)