... as single "internal compiler error" entry point.
The macros pass `file!()`, `line!()` and `format_args!(...)` on to a
cold, never-inlined function, ultimately calling `bug()` or `span_bug()`
on the `Handler` from `session::diagnostic()` via the tcx in tls or,
failing that, panicking directly.
Integrate privacy into field and method selection
This PR integrates privacy checking into field and method selection so that an inaccessible field/method can not stop an accessible field/method from being used (fixes#12808 and fixes#22684).
r? @eddyb
diagnostics: make paths to external items more visible
This PR changes the reported path for an external item so that it is visible from at least one local module (i.e. it does not use any inaccessible external modules) if possible. If the external item's crate was declared with an `extern crate`, the path is guarenteed to use the `extern crate`.
Fixes#23224, fixes#23355, fixes#26635, fixes#27165.
r? @nrc
Also adds a new set of passes to run just before translation that
"prepare" the MIR for codegen. Removal of landing pads, region erasure
and break critical edges are run in this pass.
Also fixes some merge/rebase errors.
Book: Fix phrasing: “an associated type” → “an object with an associated type”.
From what I understood, `graph` is the object from which we create a trait object, and the associated types are `Graph::N` and `Graph::E`.
Remove no longer necessary coercions to fn pointer types.
Originally added in 8fe9e4dff6.
Everything appears to build fine without the coercions, so they can
presumably be removed.
Gate parser recovery via debugflag
Gate parser recovery via debugflag
Put in `-Z continue_parse_after_error`
This works by adding a method, `fn abort_if_no_parse_recovery`, to the
diagnostic handler in `syntax::errors`, and calling it after each
error is emitted in the parser.
(We might consider adding a debugflag to do such aborts in other
places where we are currently attempting recovery, such as resolve,
but I think the parser is the really important case to handle in the
face of #31994 and the parser bugs of varying degrees that were
injected by parse error recovery.)
r? @nikomatsakis
parser recovery (so that expected errors match up)
I'm opting into parser recovery in all these cases out of expediency,
not because the error messages you get with recovery enabled are
actually all that usable in all cases listed.
This works by adding a boolean flag, `continue_after_error`, to
`syntax::errors::Handler` that can be imperatively set to `true` or
`false` via a new `fn set_continue_after_error`.
The flag starts off true (since we generally try to recover from
compiler errors, and `Handler` is shared across all phases).
Then, during the `phase_1_parse_input`, we consult the setting of the
`-Z continue-parse-after-error` debug flag to determine whether we
should leave the flag set to `true` or should change it to `false`.
----
(We might consider adding a debugflag to do such aborts in other
places where we are currently attempting recovery, such as resolve,
but I think the parser is the really important case to handle in the
face of #31994 and the parser bugs of varying degrees that were
injected by parse error recovery.)
