Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and
subsequent changes making it more correct), where the visitor will skip any
pieces of the AST that are from "foreign code", where the spans don't line up,
indicating that that piece of code is due to a macro expansion.
If this breaks your code, read the error message to determine which feature
gate you should add to your crate.
Closes#18102
[breaking-change]
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and
subsequent changes making it more correct), where the visitor will skip any
pieces of the AST that are from "foreign code", where the spans don't line up,
indicating that that piece of code is due to a macro expansion.
If this breaks your code, read the error message to determine which feature
gate you should add to your crate, and bask in the knowledge that your code
won't mysteriously break should you try to use the 1.0 release.
Closes#18102
[breaking-change]
r? @huonw or @alexcrichton
Apparently, we have previously rejected an RFC like this. However, since then we removed `{:?}` and so without this debugging gets really difficult as soon as there is a RefCell anywhere, so I believe there is more benefit to adding these impls than there was before. By using "try_borrow" we can avoid panicing in `Show` (I think).
@ huon in response to a comment in #19254: I noticed that `drop()` checks for the ptr being null, so I checked here too. Now I am checking for both, if you're confident I can change to only checking `strong()`.
The the last argument of the `ItemDecorator::expand` method has changed to `Box<FnMut>`. Syntax extensions will break.
[breaking-change]
---
This PR removes pretty much all the remaining uses of boxed closures from the libraries. There are still boxed closures under the `test` directory, but I think those should be removed or replaced with unboxed closures at the same time we remove boxed closures from the language.
In a few places I had to do some contortions (see the first commit for an example) to work around issue #19596. I have marked those workarounds with FIXMEs. In the future when `&mut F where F: FnMut` implements the `FnMut` trait, we should be able to remove those workarounds. I've take care to avoid placing the workaround functions in the public API.
Since `let f = || {}` always gets type checked as a boxed closure, I have explictly annotated those closures (with e.g. `|&:| {}`) to force the compiler to type check them as unboxed closures.
Instead of removing the type aliases (like `GetCrateDataCb`), I could have replaced them with newtypes. But this seemed like overcomplicating things for little to no gain.
I think we should be able to remove the boxed closures from the languge after this PR lands. (I'm being optimistic here)
r? @alexcrichton or @aturon
cc @nikomatsakis
is still probably wrong since it fails to incorporate the ambiguity
resolution measures that `select` uses. Also, made more complicated by
the fact that trait object types do not impl their own traits yet.
