Optimize local linkchecker program
I noticed on a [recent build][1] that the linkchecker stage of CI took a
whopping 15 minutes of CI time for something that should be near
instantaneous. Some local profiling showed some very hot functions and
clones which were pretty easy to remove, and now instead of running in
minutes locally it runs in seconds.
[1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu
rustc 1.30.0's linker flavor inference is a non-backwards compat change to -Clinker
Part of #55396.
This commit modifies linker flavor inference to only remove the extension
to the linker when performing inference if that extension is a 'exe'.
r? @nagisa
cc @alexcrichton @japaric
Reuse the `P` in `InvocationCollector::fold_{,opt_}expr`.
This requires adding a new method, `P::filter_map`.
This commit reduces instruction counts for various benchmarks by up to
0.7%.
Add TryFrom<&[T]> for [T; $N] where T: Copy
`TryFrom<&[T]> for &[T; $N]` (note *reference* to an array) already exists, but not needing to dereference makes type inference easier for example when using `u32::from_be_bytes`.
Also add doc examples doing just that.
Assorted tweaks
- preallocate `VecDeque` in `Decodable::decode` (as it is done with other collections which can do it)
- add a FIXME to `String::from_utf16`
r? @RalfJung
Use sort_by_cached_key when the key function is not trivial/free
I'm not 100% sure about `def_path_hash` (everything it does is inlined) but it seems like a good idea at least for the rest, as they are cloning.
Decouple proc_macro from the rest of the compiler.
This PR removes all dependencies of `proc_macro` on compiler crates and allows multiple copies of `proc_macro`, built even by different compilers (but from the same source), to interoperate.
Practically, it allows:
* running proc macro tests at stage1 (I moved most from `-fulldeps` to the regular suites)
* using proc macros in the compiler itself (may require some rustbuild trickery)
On the server (i.e. compiler front-end) side:
* `server::*` traits are implemented to provide the concrete types and methods
* the concrete types are completely separated from the `proc_macro` public API
* the only use of the type implementing `Server` is to be passed to `Client::run`
On the client (i.e. proc macro) side (potentially using a different `proc_macro` instance!):
* `client::Client` wraps around client-side (expansion) function pointers
* it encapsulates the `proc_macro` instance used by the client
* its `run` method can be called by a server, to execute the client-side function
* the client instance is bridged to the provided server, while it runs
* ~~currently a thread is spawned, could use process isolation in the future~~
(not the case anymore, see #56058)
* proc macro crates get a generated `static` holding a `&[ProcMacro]`
* this describes all derives/attr/bang proc macros, replacing the "registrar" function
* each variant of `ProcMacro` contains an appropriately typed `Client<fn(...) -> ...>`
`proc_macro` public APIs call into the server via an internal "bridge":
* only a currently running proc macro `Client` can interact with those APIs
* server code might not be able to (if it uses a different `proc_macro` instance)
* however, it can always create and `run` its own `Client`, but that may be inefficient
* the `bridge` uses serialization, C ABI and integer handles to avoid Rust ABI instability
* each invocation of a proc macro results in disjoint integers in its `proc_macro` handles
* this prevents using values of those types across invocations (if they even can be kept)
r? @alexcrichton cc @jseyfried @nikomatsakis @Zoxc @thepowersgang
I noticed on a [recent build][1] that the linkchecker stage of CI took a
whopping 15 minutes of CI time for something that should be near
instantaneous. Some local profiling showed some very hot functions and
clones which were pretty easy to remove, and now instead of running in
minutes locally it runs in seconds.
[1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu
libcore: Add VaList and variadic arg handling intrinsics
## Summary
- Add intrinsics for `va_start`, `va_end`, `va_copy`, and `va_arg`.
- Add `core::va_list::VaList` to `libcore`.
Part 1 of (at least) 3 for #44930
Comments and critiques are very much welcomed 😄
Rollup of 22 pull requests
Successful merges:
- #55391 (bootstrap: clean up a few clippy findings)
- #56021 (avoid features_untracked)
- #56023 (atomic::Ordering: Get rid of misleading parts of intro)
- #56080 (Reduce the amount of bold text at doc.rlo)
- #56114 (Enclose type in backticks for "non-exhaustive patterns" error)
- #56124 (Fix small doc mistake on std::io::read::read_to_end)
- #56127 (Update an outdated comment in mir building)
- #56148 (Add rustc-guide as a submodule)
- #56149 (Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer)
- #56220 (Suggest appropriate place for lifetime when declared after type arguments)
- #56223 (Make JSON output from -Zprofile-json valid)
- #56236 (Remove unsafe `unsafe` inner function.)
- #56255 (Update outdated code comments in StringReader)
- #56257 (rustc-guide has moved to rust-lang/)
- #56273 (Add missing doc link)
- #56289 (Fix small typo in comment of thread::stack_size)
- #56294 (Fix a typo in the documentation of std::ffi)
- #56312 (Deduplicate literal -> constant lowering)
- #56319 (fix futures creating aliasing mutable and shared ref)
- #56321 (rustdoc: add bottom margin spacing to nested lists)
- #56322 (resolve: Fix false-positives from lint `absolute_paths_not_starting_with_crate`)
- #56330 (Clean up span in non-trailing `..` suggestion)
Failed merges:
r? @ghost
fix futures creating aliasing mutable and shared ref
Fixes the problem described in https://github.com/solson/miri/issues/532#issuecomment-442552764: `set_task_waker` takes a shared reference and puts a copy into the TLS (in a `NonNull`), but `get_task_waker` gets it back out as a mutable reference. That violates "mutable references must not alias anything"!
Remove unsafe `unsafe` inner function.
Within this `Iterator` implementation, a function `unsafe_get` is
defined which unsafely allows _unchecked_ indexing of any element in a
slice. This should be marked as _unsafe_, but it is not.
To address this issue, I removed that inner function.
Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer
I was confused by this API so I clarified what they are doing.
I was wondering if I should try to unify more documentation and examples between `unix` and `linux` (e.g. “of the file” is used in `unix` to refer to the file these metadata is for, “of this file” in `linux`, “of the underlying file” in `std::fs::File`).
Add rustc-guide as a submodule
Adding this as a submodule will allow two things:
- Linking to the guide from doc.rlo
- Doing a link check as part of the rust CI build
Key question: Do we want to wait for the book to be filled out more? e.g. do we ever want to move it out of the nursery?
r? @nikomatsakis
cc @steveklabnik
