This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes#47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
Introduce UnpackedKind
This adds an `UnpackedKind` type as a typesafe counterpart to `Kind`. This should make future changes to kinds (such as const generics!) more resilient, as the type-checker will be able to catch more potential issues.
r? @eddyb
cc @yodaldevoid
rustdoc: don't crash when an external trait's docs needs to import another trait
Fixes https://github.com/rust-lang/rust/issues/48414
When resolving intra-paths for an item, rustdoc needs to have information about their items on hand, for proper bookkeeping. When loading a path for an external item, it needs to load these items from their host crate, since their information isn't otherwise available. This includes resolving paths for those docs. which can cause this process to recurse. Rustdoc keeps a map of external traits in a `RefCell<HashMap<DefId, Trait>>`, and it keeps a borrow of this active when importing an external trait. In the linked crash, this led to a RefCell borrow error, panic, and ICE.
This PR manually releases the borrow while importing the trait, and also keeps a list of traits being imported at the given moment. The latter keeps rustdoc from infinitely recursing as it tries to import the same trait repeatedly.
Update the book to promote second edition
This updates the book repository, but mostly to include
https://github.com/rust-lang/book/pull/1180
TL;DR: the second edition is close enough to done that we should
universally recommend it over the first edition.
Fix exponential projection complexity on nested types
This implements solution 1 from https://github.com/rust-lang/rust/issues/38528#issuecomment-366263076.
The code quality is currently extremely poor, but we can improve them during review.
Blocking issues:
- we probably don't want a quadratic deduplication for obligations.
- is there an alternative to deduplication?
Based on #48315.
Needs changelog. Noticable improvement on compile time is expected.
Fix#38528Close#39684Close#43757
Allow two-phase borrows of &mut self in ops
We need two-phase borrows of ops to be in the initial NLL release since without them lots of existing code will break. Fixes#48129.
CC @pnkfelix and @nikomatsakis
r? @pnkfelix
Fix borrow checker unsoundness with unions
Fixes#45157. After discussion with @nikomatsakis on Gitter, this PR only adds a test since the original issue was resolved elsewhere.
r? @nikomatsakis
Allow for instantiating statics from upstream crates
This PR makes the infrastructure around translating statics a bit more flexible so that it can also instantiate statics from upstream crates if the need arises. This is preparatory work for a MIR-only RLIBs prototype, where the instantiation of a `static` may be deferred until a leaf crate.
r? @eddyb (feel free to assign to someone else if you're busy)
save-analysis: power through bracket mis-counts
Closes#47981
This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here.
r? @eddyb
Remove "static item recursion checking" in favor of relying on cycle checks in the query engine
Tests are changed to use the cycle check error message instead. Some duplicate tests are removed.
r? @eddyb
Split MinGW tests into two builders on AppVeyor
Run-pass and compile-fail tests appear to take the most significant chunk of time, so split them into their own builder.
Should help with https://github.com/rust-lang/rust/issues/46903.
r? @kennytm
cc @alexcrichton
[docs] Minor wording changes to drain_filter docs
The docs currently say, "If the closure returns false, it will try again, and call the closure on the next element." But this happens regardless of whether the closure returns true or false.
Overhaul improper_ctypes output
This snowballed into a rather big set of improvements to the diagnostics of the improper_ctypes lint. See commits for details, including effects of each change on the `compile-fail/improper-ctypes.rs` test (now a UI test), which is pretty gnarly and hopefully not representative of real code, but covers a lot of different error cases.
Fixes#42050
detect wrong number of args when type-checking a closure
Instead of creating inference variables for those argument types, use
the trait error-reporting code to give a nicer error. This also
improves some other spans for existing tests.
Fixes#47244
r? @estebank
