permit `crate` in absolute paths

[nikomatsakis]

As part of #44660, we plan to support absolute paths that begin with crate. The RFC was actually a bit vague about how crate::foo paths work outside of use items. I'm going to go with the interpretation described by @rpjohnst, that one would write ::crate::foo to reference the item foo from outside of a use statement.

This means we want to support use statements like this:

use crate::foo::bar; // equivalent to `use foo::bar` today.

and "absolute" code references like this:

fn baz() {
    ::crate::foo::bar() // equivalent to `::foo::bar` today
}

This version also avoids a parsing ambiguity around tuple structs and the crate visibility modifier:

struct Foo(crate ::crate::Bar)

[power10dan]

Interesting. Mind if I give this a try? If yes, where should I start to investigate this?

[nikomatsakis]

@power10dan

Mind if I give this a try?

I would love it if you did! I started the other day trying to write up mentoring instructions, but I never quite finished. This gist contains what I did so far. Maybe the best way to start is just to read a bit into some of the code mentioned there, to get a feeling for how things work today. You can reach out on gitter with questions, too.

I will try to extend the directions, or perhaps @petrochenkov has thoughts -- he knows this part of the code better than I.

[power10dan]

Got it. It seems that @petrochenkov has self-assigned the issue to him. I did message him on gitter to ask whether he needed help. Nevertheless, I will go through the code base, and if there is anything I find interesting while working on this issue I will be sure to extend the directions.

[power10dan]

So @petrochenkov is not working on this issue. Can I get assigned to this issue please? I don't think I have permission to self-assign.

[power10dan]

Sorry for spamming. I think only repo members can assign assignees to the project. So I will just leave a comment that I will be working on this issue :)

[petrochenkov]

@power10dan

only repo members can assign assignees to the project.

Moreover, only repo members can be assigned to the repo issues on GitHub, so I can't add you to the "Assignees" list either.

[power10dan]

Hi,

So what's the best way to test the parser that I wrote for this issue? I understand that there is a file called testparser.py within the project directory. However, how can I invoke the testparser.py to test specifically my changes? Do I need to augment testparser.py? Or do I have to write unit tests on a separate file, call the function that I wrote within the unit tests and test it against custom test cases?

[petrochenkov]

@power10dan
You can freely ignore everything in src\grammar including testparser.py, it's not where actual parsing happens, the actual parser is src\libsyntax\parse\parser.rs.
Parser changes can be tested in the same way as other compiler changes, by adding a new test into src\test\parse-fail or src\test\run-pass and running x.py test --stage 1 src/test/parse-fail --test-args my-new-test-name. See https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md for more details.

[petrochenkov]

Mentoring instructions from @nikomatsakis in #45477 (comment) seem to be much more complex than what's needed to do the job.

There are three places that need to be tweaked:

• is_path_segment_keyword, crate does need to be added to that list
• parse_path_common should avoid inserting CrateRoot into the path if the path starts with ::crate, and should report a non-fatal error if the path starts with crate (unless it's an import or visibility path).
• resolve_path should treat Crate exactly as CrateRoot.
• Extra: search keywords::DollarCrate and keywords::CrateRoot and look for other places that maybe need to be tweaked, e.g. pretty-printing.

Alternative implementation:

• is_path_segment_keyword, crate does need to be added to that list
• no changes in the parser, tweak default_to_global to still insert CrateRoot even for crate::... paths.
• resolve_path should treat two-segment prefix [CrateRoot, Crate] exactly as CrateRoot.
• Extra: same.

[power10dan]

@petrochenkov I also feel that the mentor instruction is a bit complex too. My thoughts for implementing this are the following : ( I am working on the use crate :: case)

1. Use regex to see if the pattern starts with use followed by crate. For example, if the person typed use crate::foo::bar, a regex for this might be ^use\scrate*$, where we test if the expression starts with use followed by a space \s followed by crate and followed by whatever. This is my first thought, and I am not really sure if this is the correct way to go.

2. For the absolute code reference case, we can come up with a regex to check if the expression ::crate::foo::bar is between a function, and then parse it.

I think my approach is a bit more complex than it needs to be. But I think I will take @petrochenkov 's advice. What do you guys think?