Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Failed merges:
r? @ghost
They used to be covered by `optin_builtin_traits` but negative impls
are now applicable to all traits, not just auto traits.
This also adds docs in the unstable book for the current state of auto traits.
This flag opts out of the min-const-fn checks entirely, which is usually
not what we want. The few cases where the flag is still necessary have
been annotated.
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
Split off from #62855
This PR deerializes the declaration `Span` and attributes for all
procedural macros from their underlying function definitions.
This allows Rustdoc to properly render doc comments
and source links when inlining procedural macros across crates
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
This updates the `Extend` implementations to use `for_each` for many
collections: `BinaryHeap`, `BTreeMap`, `BTreeSet`, `LinkedList`, `Path`,
`TokenStream`, `VecDeque`, and `Wtf8Buf`.
Folding with `for_each` enables better performance than a `for`-loop for
some iterators, especially if they can just forward to internal
iterators, like `Chain` and `FlatMap` do.
Introduce proc_macro::Span::source_text
A function to extract the actual source behind a Span.
Background: I would like to use `syn` in a `build.rs` script to parse the rust code, and extract part of the source code. However, `syn` only gives access to proc_macro2::Span, and i would like to get the source code behind that.
I opened an issue on proc_macro2 bug tracker for this feature https://github.com/alexcrichton/proc-macro2/issues/110 and @alexcrichton said the feature should first go upstream in proc_macro. So there it is!
Since most of the Span API is unstable anyway, this is guarded by the same `proc_macro_span` feature as everything else.
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
David Tolnay