Issue 1:
A (personal) user experience:

While looking for matching functionality on str, I went to the following link:

mod str: https://doc.rust-lang.org/std/str/index.html

note that this is distinct from primitive str: https://doc.rust-lang.org/std/primitive.str.html

you may not realize that at first glance; see further commentary below

note also that the mod str link occurs first in the search results (primitive second): https://doc.rust-lang.org/std/str/?search=str

The mod str documentation, at first blush, seems promising; it describes the str type quickly, shows examples of &str and discusses its representation. It then lists a bunch of structs that seem promising. Things like struct Matches "created with the method .matches()"

But then I see no method list. And the text "created with the method .matches()" does not have a hyperlink to that method. Following the link to the page for struct Matches does not help. (I can imagine reasons why we would not want to flood the embedded identifiers with hyperlinks; I'm just pointing out that one reasonable guess at how to find this method does not work out.)

Anyway, perhaps a lot of this confusion would be reduced if, at the very beginning of the documentation for mod str, we included a prominent link to the primitive str documentation page, which does have all of these methods.

But, there is a twist (which perhaps should be a different bug).

mod str: https://doc.rust-lang.org/std/str/index.html

note that this is distinct from primitive str: https://doc.rust-lang.org/std/primitive.str.html

Both of these pages start off with the exact same text. Apart from the respective titles ("Module std::str" versus "Primitive Type str"), there is no visible difference in my web browser which is filling its vertical space on my laptop, because the differences only start after the "Representation" section, and I need to scroll to see that.

This is not great, because someone who is following links trying to find the right page after starting from the mod str docs might reasonably think that this link took them back to the mod str docs.

Issue 2:
There are a number of problems with our current quote_expr!, quote_tokens!, etc. macros. The first one is that they're cloaking/unhygienic. Fixing this is easy--just change the macro definition so that you have to supply an identifier as the first argument.

The second problem is that they really shouldn't work in the way that they do.

Specifically, these macros currently expand into ASTs that represent calls to the parser, thereby generating an AST. This discards all context/hygiene information, and is also inefficient, since you already have the AST that you're trying to protect.

Languages such as Racket just provide a language primitive called "quote-syntax" whose evaluation rule is literally the trivial one--a use of quote-syntax simply evaluates to the AST on the right hand side of the call.

What would it take to add this to Rust?

You'd need a new AST node called (say) quote_expr.

The typechecker would have to know that any quote_ast node trivially has the type ast::expr -- no checking required.

This should be less than a day of work for someone who really understands the system well. One question is whether you want to duplicate this work for each of the quote_... thingies, or make one that covers them all, with some kind of simple enum.

It appears to me that it would also allow us to throw out a huge amount of code--all of the quoting stuff that's in there currently.