box/in desugaring leads to inscrutable error messages

[pnkfelix]

spawned off of #22086

Some of the error messages from e.g. typeck get significant worse when reported from the depths of desugared code rather than from the high level syntax.

For example: this:

static STATIC11: Box<MyOwned> = box MyOwned;
//~^ ERROR statics are not allowed to have custom pointers

turns into this:

static STATIC11: Box<MyOwned> = box MyOwned;
//~^ ERROR statics are not allowed to have destructors
//~| ERROR statics are not allowed to have destructors
//~| ERROR statics are not allowed to have destructors
//~| ERROR statics are not allowed to have mutable references
//~| ERROR cannot borrow a local variable inside a static block

(because of all the things the desugared code does that is not legal within the context of a static block.

We should try to address this in some way; since we have control over the desugaring, the static analyses, and the error reporting system, one can imagine we should be able to mark the expressions and/or spans and/or error sources in such a way that the compiler can present a higher level "box expression are not supported in static blocks" and suppress the other messages.

(Note that I am speaking of a desugaring implemented within libsyntax itself; we already attempt to address this problem with macro_rules! macros by providing a stack trace of the expansion there, for better or for worse.)

[pnkfelix]

cc #22181

[steveklabnik]

This specific example is much nicer today:

#![feature(box_syntax)]
struct MyOwned;
static STATIC11: Box<MyOwned> = box MyOwned;

gives

src/lib.rs:3:33: 3:44 error: allocations are not allowed in statics [E0010]
src/lib.rs:3 static STATIC11: Box<MyOwned> = box MyOwned;
                                             ^~~~~~~~~~~

can this be closed, then, or are there other cases?

[Mark-Simulacrum]

I'm going to close pending other examples. Please reopen with those if they exist.