Add discr_index to multi-variant layouts
We remove the assumption that the discriminant is always field 0, in
preparations for layouts like generators where this is not (always) going to be
the case.
Specifically, upvars are going to go before the discriminant. In theory, it's possible to remove _that_ assumption instead and keep the discriminant at field index 0, but one assumption or the other had to go :)
There is one place I know of in the debuginfo code where we'll still need to remove assumptions that the discriminant is the _only_ field. I was planning on doing this along with the upcoming generator change, which will also include tests that exercise the code changing in this PR.
r? @eddyb
cc @oli-obk
cc @cramertj
save-analysis: Pull associated type definition using `qpath_def`
Closes https://github.com/rust-lang/rls/issues/1390
This (probably?) fixes the case where we run the save-analysis code on the following snippet:
```rust
trait Test<'a> {
type Thing: Test2;
}
trait Test2 {
fn print();
}
#[allow(unused)]
fn example<T>(t: T)
where T: for<'a> Test<'a>
{
T::Thing::print(); //~ ERROR cannot extract an associated type from a higher-ranked trait bound in this context
// ^ only errors in save-analysis mode
}
```
The chain is as follows:
- culprit is `hir_ty_to_ty`
- which calls `ast_ty_to_ty` in the `ItemCtxt`
- which calls `associated_path_to_ty`
- which finally fails on `projected_ty_from_poly_trait_ref`
3de0106789/src/librustc_typeck/collect.rs (L212-L224)
I'm not exactly sure why `hir_ty_to_ty` fails - is it because it needs more setup from typeck to work correctly? I'm guessing the fix is okay since we just pull the already typeck'd data (we run save-analysis after all the analysis passes are complete) from the tables.
With this change we can 'go to def' on all segments in the `T::Thing::print()` path.
Remove strange formatting in `Ordering` docs.
I can't really fathom what the intent of the brackets is. The [original PR](#12956) doesn't give any hints. I think it seems fine without them.
Kill dead code dominator code.
Hi,
Whilst fiddling around in the dominator code, I found some (I think) unused code. This code *was* used at the time it was imported, but over time it seems to have become redundant.
I've tested a build up to stage 1 with no problems. Maybe the tests will turn up something though.
P.S.
There is a FIXME comment in `dominators/mod.rs`:
```
pub fn is_dominated_by(&self, node: Node, dom: Node) -> bool {
// FIXME -- could be optimized by using post-order-rank
self.dominators(node).any(|n| n == dom)
}
```
I'm not sure of the intention of this comment. The `Dominators` struct already operates over post-order rank nodes. Any ideas?
compiletest: Improve no_prefer_dynamic docs
This adds some extra docs for the `no-prefer-dynamic` header.
And also a `s/must_compile_successfully/compile_pass`.
`must_compile_successfully` has been renamed to `compile_pass` at some
point in the past and this comment was still referring to the old name.
Document the -Z flag to the rustc book
# Description
Changes:
- Added new documentation on the `-Z` flag of rustc in the command-line arguments section of the rustc book.
If I need to rephrase anything or if you have any improvements, please let me know! I deliberately did not create an exhaustive list of all options since they are likely to change over time and per toolchain version.
closes#41142
musl: do not compress debug section
This should be beta nominated.
Fixes https://github.com/rust-lang/rust/issues/59411 (this time for real).
Test with `DEPLOY=1 ./src/ci/docker/run.sh dist-x86_64-musl`, without `DEPLOY=1` libs are built without debuginfo.
r? @alexcrichton
Introduce RefCell::try_borrow_unguarded
*Come sit next to the fireplace with me, this is going to be a long story.*
So, you may already be aware that Servo has weird design constraints that forces us developers working on it to do weird things. The thing that interests us today is that we do layout on a separate thread with its own thread pool to do some things in parallel, whereas the data it uses comes from the script thread, which implements the entire DOM and related pieces, with `!Sync` data types such as `RefCell<T>`.
The invariant we maintain is that script does not do anything ever with the DOM data as long as layout is doing its job. That's all nice and all, but one thing we don't ensure is that we don't actually know if script was currently mutably borrowing some `RefCell<T>` prior to starting layout, which may lead to aliasing mutable memory and obviously undefined behaviour.
This PR reinstates `RefCell::borrow_state` so that [this method](https://github.com/servo/servo/blob/master/components/script/dom/bindings/cell.rs#L23-L30) can make use of it and return `None` if the cell was mutably borrowed.
Cc @SimonSapin
rustdoc: don't process `Crate::external_traits` when collecting intra-doc links
Part of https://github.com/rust-lang/rust/issues/58745, closes https://github.com/rust-lang/rust/pull/58917
The `collect-intra-doc-links` pass keeps track of the modules it recurses through as it processes items. This is used to know what module to give the resolver when looking up links. When looking through the regular items of the crate, this works fine, but the `DocFolder` trait as written doesn't just process the main crate hierarchy - it also processes the trait items in the `external_traits` map. This is useful for other passes (so they can strip out `#[doc(hidden)]` items, for example), but here it creates a situation where we're processing items "outside" the regular module hierarchy. Since everything in `external_traits` is defined outside the current crate, we can't fall back to finding its module scope like we do with local items.
Skipping this collection saves us from emitting some spurious warnings. We don't even lose anything by skipping it, either - the docs loaded from here are only ever rendered through `html::render::document_short` which strips any links out, so the fact that the links haven't been loaded doesn't matter. Hopefully this removes most of the remaining spurious resolution warnings from intra-doc links.
r? @GuillaumeGomez
