The parser should use some kind of hygiene or lang item for FullRange

[nrc]

The parser currently assumes there is a struct called FullRange in scope in order to desugar full slices (&expr[] -> &expr[FullRange]). This is a problem if there is no prelude (where FullRange is defined).

We already have a lang item for FullRange, but unfortunately lang items can only be used from the compiler proper, not from libsyntax. The ideal solution is to fix that. Shorter term we might want to allow a full path to be specified via a macro or something, so we can be a bit more hygenic here.

[emberian]

I suspect the easiest way to do this would be to add another "special ident", and expand to that.

[nrc]

@cmr I already do that, but it is not as flexible as a lang item

[nikomatsakis]

is this a dup of #21263?

[emberian]

this is one strategy for implementing it.

[kmcallister]

Maybe the libsyntax counterpart to lang items would be "lang macros".

#[lang="range_full"]
// Implicitly exported, but not in the usual way
macro_rules! name_doesnt_matter {
    () => ( $crate::ops::RangeFull )
}

This opens the intriguing possibility of moving more sugar, such as for loops, into the standard library. That could have negative effects on error reporting though; it certainly would until #20923 is fixed.

Any sugar defined through lang macros could be redefined by #![no_std] crates, in a manner similar to GHC's -XRebindableSyntax. We should make sure that they can't be re-defined / shadowed without the lang_items gate.

Whether or not we find lang macros to be widely useful, it seems like a fine solution to the problem at hand.

[alexcrichton]

FullRange no longer exists and I believe this is no longer an issue.