Use Span
s to detect "system crate"s, for error deferral (zombie) purposes.
#952
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this PR, the distinction between "user code" and "system code" (e.g.
core
APIs) was based on the crate "doing the codegen", but#[inline]
/genericfn
s (and even macros) can cause e.g.core
internals to be codegen'd during the compilation of an user crate.This used to not be a big issue, because "zombies" (i.e. deferred errors) only get silenced when they're in unused code, so they mostly served to hide errors in e.g.
core
internals that would not be codegen'd at all, had they had#[inline]
.However, we've accumulated several features which rely on hiding various potentially-zombie things (such as the panic entry-point hijacking, or the "unused
fn
params" weakening), so we need to be using "zombies" (i.e. deferring errors) as much as possible, in order to actually take advantage of that infrastructure.(I could've gone further and removed
is_system_crate
, forcingzombie_even_in_user_code
's behavior always, but that might lead to confusing outcomes, so I decided against it - for now, anyway)