NB: Since we are using the same InferCtxt in each iteration,
we essentially *spoil* the inference variables and we only
ever get at most *one* applicable candidate (only the 1st candidate
has clean variables that can still unify correctly).
Rollup of 5 pull requests
Successful merges:
- #107766 (Fix json reexports of different items with same name)
- #108129 (Correctly handle links starting with whitespace)
- #108188 (Change src/etc/vscode_settings.json to always treat ./library as the sysroot source)
- #108203 (Fix RPITITs in default trait methods (by assuming projection predicates in param-env))
- #108212 (Download rustfmt regardless of rustc being set in config.toml)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix RPITITs in default trait methods (by assuming projection predicates in param-env)
Instead of having special projection logic that allows us to turn `ProjectionTy(RPITIT, [Self#0, ...])` into `OpaqueTy(RPITIT, [Self#0, ...])`, we can instead augment the param-env of default trait method bodies to assume these as projection predicates. This should allow us to only project where we're allowed to!
In order to make this work without introducing a bunch of cycle errors, we additionally tweak the `OpaqueTypeExpander` used by `ParamEnv::with_reveal_all_normalized` to not normalize the right-hand side of projection predicates. This should be fine, because if we use the projection predicate to normalize some other projection type, we'll continue to normalize the opaque that it gets projected to.
This also makes it possible to support default trait methods with RPITITs in an associated-type based RPITIT lowering strategy without too much extra effort.
Fixes#107002
Alternative to #108142
Change src/etc/vscode_settings.json to always treat ./library as the sysroot source
See
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/False.20error.20report.20for.20.60rust-analyzer.28private-field.29.60 for further discussion; previously this had various bugs.
I tested go-to-definition on:
- `use std::io::Write` in `src/bootstrap/setup.rs`
- `use std::cell::RefCell` in `src/librustdoc/core.rs`
- `use rustc_span::symbol::sym` in `src/librustdoc/core.rs`
- `use std::fmt` in `compiler/rustc_span/src/symbol.rs`
- `Global` in `library/alloc/src/alloc/tests.rs`
The following things still don't work:
- `Global.deallocate` in alloc/tests.rs. This function is under `cfg(not(test))`, so it can't be enabled without disabling RA in `tests.rs` altogether. I think this might be fixable by moving `library/alloc/src/alloc/tests.rs` to `library/alloc/tests/alloc/lib.rs`, so it's in a different crate, but I'd like to avoid blocking this improvement on that change.
cc `@thomcc` `@BoxyUwU` `@spastorino` - you've had issues with RA in the past, does this fix them? Are there any other use cases I should test? You can try these changes out by running `cp src/etc/vscode_settings.json .vscode/settings.json`, or running `x setup` and picking a random profile (it won't overwrite config.toml if it already exists). See https://github.com/rust-lang/rust/pull/108135 for plans to make updating the config easier.
r? `@Veykril`
Correctly handle links starting with whitespace
Part of https://github.com/rust-lang/rust/issues/107995.
I just got this issue, wrote a fix and then saw the issue. So here's the PR. ^^'
r? `@petrochenkov`
Fix json reexports of different items with same name
Fixes #107677.
I renamed `from_item_id*` functions into `id_from_item` instead because it makes more sense now. I also simplified the logic around it a bit so that the `ids` function will now directly pass `&clean::Item` to `id_from_item` and the ID will be consistently generated (it caused an issue when I updated the ID for imports).
So now, the big change of this PR: I changed how imports' ID is generated: it now includes the target item's ID at the end of the ID. It's to prevent two reexported items with the same name (but different types).
r? `@aDotInTheVoid`
Rollup of 7 pull requests
Successful merges:
- #104659 (reflow the stack size story)
- #106933 (Update documentation of select_nth_unstable and select_nth_unstable_by to state O(n^2) complexity)
- #107783 (rustdoc: simplify DOM for `.item-table`)
- #107951 (resolve: Fix doc links referring to other crates when documenting proc macro crates directly)
- #108130 ("Basic usage" is redundant for there is just one example)
- #108146 (rustdoc: hide `reference` methods in search index)
- #108189 (Fix some more `non_lifetime_binders` stuff with higher-ranked trait bounds)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix some more `non_lifetime_binders` stuff with higher-ranked trait bounds
1. When assembling candidates for `for<T> T: Sized`, we can't ICE because the self-type is a bound type.
2. Fix an issue where, when canonicalizing in non-universe preserving mode, we don't actually set the universe for placeholders to the root even though we do the same for region vars.
3. Make `Placeholder("T")` format like `T` in error messages.
Fixes#108180Fixes#108182
r? types
rustdoc: simplify DOM for `.item-table`
This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
Make `dyn*`'s value backend type a pointer
One tweak on top of Ralf's commit should fix using `usize` as a `dyn*`-coercible type, and should fix when we're using various other pointer types when LLVM opaque pointers is disabled.
r? `@eholk` but feel free to reassign
cc https://github.com/rust-lang/rust/pull/107728#issuecomment-1421231823 `@RalfJung`
Check that built-in callable types validate their output type is `Sized` (in new solver)
Working on parity with old solver. Putting this up for consideration, it's not *really* needed or anything just yet. Maybe it's better to approach this from another direction (like always checking the item bounds when calling `consider_assumption`? we may need that for coinduction to be sound though?)
This basically implements #100096 for the new solver.
Don't call `with_reveal_all_normalized` in const-eval when `param_env` has inference vars in it
**what:** This slightly shifts the order of operations from an existing hack:
5b6ed253c4/compiler/rustc_middle/src/ty/consts/kind.rs (L225-L230)
in order to avoid calling a tcx query (`TyCtxt::reveal_opaque_types_in_bounds`, via `ParamEnv::with_reveal_all_normalized`) when a param-env has inference variables in it.
**why:** This allows us to enable fingerprinting of query keys/values outside of incr-comp in deubg mode, to make sure we catch other places where we're passing infer vars and other bad things into query keys. Currently that (bbf33836b9) crashes because we introduce inference vars into a param-env in the blanket-impl finder in rustdoc 😓5b6ed253c4/src/librustdoc/clean/blanket_impl.rs (L43)
See the CI failure here: https://github.com/rust-lang/rust/actions/runs/4058194838/jobs/6984834619
