arena: speed up TypedArena::clear and improve common patterns
- speed up `TypedArena::clear`: improves its performance by up to **33%** (in case of a single entry)
- simplify `DroplessArena::in_arena`
experiment: Support aliasing local crate root in extern prelude
This PR provides some minimally invasive solution for the 2018 edition migration issue described in https://github.com/rust-lang/rust/issues/54647 and affecting proc macro crates.
`extern crate NAME as RENAME;` now accepts `NAME`=`self` and interprets it as referring to the local crate.
As with other `extern crate` items, `RENAME` in this case gets into extern prelude in accordance with https://github.com/rust-lang/rust/pull/54658, thus resolving https://github.com/rust-lang/rust/issues/54647.
```rust
extern crate self as serde; // Adds local crate to extern prelude as `serde`
```
This solution doesn't introduce any new syntax and has minimal maintenance cost, so it can be easily deprecated if something better is found in the future.
Closes https://github.com/rust-lang/rust/issues/54647
drop glue takes in mutable references, it should reflect that in its type
When drop glue begins, it should retag, like all functions taking references do. But to do that, it needs to take the reference at a proper type: `&mut T`, not `*mut T`.
Failing to retag can mean that the memory the reference points to remains frozen, and `EscapeToRaw` on a frozen location is a NOP, meaning later mutations cause a Stacked Borrows violation.
Cc @nikomatsakis @Gankro because Stacked Borrows
Cc @eddyb for the changes to miri argument passing (the intention is to allow passing `*mut [u8]` when `&mut [u8]` is expected and vice versa)
ci: Only run compare-mode tests on one builder
The run-pass test suite currently takes 30 minutes on Windows, and
that appears to be roughly split between two 15 minute runs of the test
suite: one without NLL and one with NLL. In discussion on Discord the
platform coverage of the NLL compare mode may not necessarily be worth
it, so this commit removes the NLL compare mode from tests by default,
and then reenables it on only one builder.
The run-pass test suite currently takes 30 minutes on Windows, and
that appears to be roughly split between two 15 minute runs of the test
suite: one without NLL and one with NLL. In discussion on Discord the
platform coverage of the NLL compare mode may not necessarily be worth
it, so this commit removes the NLL compare mode from tests by default,
and then reenables it on only one builder.
Rollup of 19 pull requests
Successful merges:
- #55011 (Add libstd Cargo feature "panic_immediate_abort")
- #55821 (Use sort_by_cached_key when the key function is not trivial/free)
- #56014 (add test for issue #21335)
- #56131 (Assorted tweaks)
- #56214 (Implement chalk unification routines)
- #56216 (Add TryFrom<&[T]> for [T; $N] where T: Copy)
- #56268 (Reuse the `P` in `InvocationCollector::fold_{,opt_}expr`.)
- #56324 (Use raw_entry for more efficient interning)
- #56336 (Clean up and streamline the pretty-printer)
- #56337 (Fix const_fn ICE with non-const function pointer)
- #56339 (Remove not used option)
- #56341 (Rename conversion util; remove duplicate util in librustc_codegen_llvm.)
- #56349 (rustc 1.30.0's linker flavor inference is a non-backwards compat change to -Clinker)
- #56355 (Add inline attributes and add unit to CommonTypes)
- #56360 (Optimize local linkchecker program)
- #56364 (Fix panic with outlives in existential type)
- #56365 (Stabilize self_struct_ctor feature.)
- #56367 (Moved some feature gate tests to correct location)
- #56373 (Update books)
Implement chalk unification routines
`ResolventOps` and `AggregateOps` are mostly straightforwardly translated from chalk. I had caught a few bugs already in my `chalk` branch and backported fixes to this branch, but there may be other ones left. EDIT: I hope there are none left now :)
Fixes#54935.
Add libstd Cargo feature "panic_immediate_abort"
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve#54981.
Update books
This pulls in @Gankro 's final nomicon changes, and adds the edition guide as a submodule.
This is the final doc backport to beta for 1.31, as well.
Moved some feature gate tests to correct location
I evidently need to create some sort of GitHub monitor tool that yells at people when they do this in their PRs. ;-)
r? @centril
Fix panic with outlives in existential type
Don't panic in determining the privacy of a type if a lifetime outlives
generic exists in an existential type.
r? @oli-obk
Fixes: #55903
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