fix(resolve): not defined `extern crate shadow_name`
Fixes https://github.com/rust-lang/rust/issues/109148
## Why does #109148 panic?
When resolving `use std::xx` it enters `visit_scopes` from `early_resolve_ident_in_lexical_scope`, and iters twice during the loop:
|iter| `scope` | `break_result` | result |
|-|-|-|-|
| 0 | `Module` pointed to root | binding pointed to `Undetermined`, so result is `None` | scope changed to `ExternPrelude` |
| 1 | `ExternPrelude` | binding pointed to `std` | - |
Then, the result of `maybe_resolve_path` is `Module(std)`, so `import.imported_module.set` is executed.
Finally, during the `finalize_import` of `use std::xx`, `resolve_path` returns `NonModule` because `Binding(Ident(std), Module(root)`'s binding points to `extern crate blah as std`, which causes the assertion to fail at `assert!(import.imported_module.get().is_none());`.
## Investigation
The question is why `#[a] extern crate blah as std` is not defined as a binding of `std::xxx`, which causes the iteration twice during `visit_scopes` when resolving `std::xxx`. Ideally, the value of `break_result.is_some()` should have been valid in the first iteration.
After debugging, I found that because `#[a] extern crate blah as std` had been dummied by `placeholder` during `collect_invocations`, so it had lost its attrs, span, etc..., so it will not be defined. However, `expand_invoc` added them back, then the next `build_reduced_graph`, `#[a] extern crate blah as std` would have been defined, so it makes the result of `resolved_path` unexpected, and the program panics.
## Try to solve
I think there has two-way to solve this issue:
- Expand invocations before the first `resolve_imports` during `fully_expand_fragment`. However, I do not think this is a good idea because it would mess up the current design.
- As my PR described: do not define to `extern crate blah as std` during the second `build_reduced_graph`, which is very easy and more reasonable.
r? `@petrochenkov`
Document stack-protector option
Only updated `exploit-mitigations.md` to reflect that the option exists. Removed the alternatives mentioned as they are not actually implemented yet.
As this is an unstable feature, should it be added to `unstable-book` also? [Example](https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html). I didn't do that because I couldn't find the tracking issue for stack-protector. (There should be one to track stabilization of the feature, I think?)
cc `@rcvalle`
Pretty-print inherent projections correctly
Previously, we were trying to pretty-print inherent projections with `Printer::print_def_path` which is incorrect since
it expects the substitutions to be of a certain format (parents substs followed by own substs) which doesn't hold for
inherent projections (self type subst followed by own substs).
Now we print inherent projections manually.
Fixes#111390.
Fixes#111397.
Lacking tests! Is there a test suite / compiletest flags for the pretty-printer? In most if not all cases,
inherent projections are normalized away before they get the chance to appear in diagnostics.
If I were to create regression tests for linked issues, they would need to be `mir-opt` tests to exercise
`-Zdump-mir=all` (right?) which doesn't feel quite adequate to me.
`@rustbot` label F-inherent_associated_types
The `rust-call` ABI isn't compatible with
`#![feature(unsized_fn_params)]`, so trying to use that feature with
closures leads to an ICE (#67981). This turns that ICE into a
type-check error.
Fixes#111515 and complements #106547 by adding support for encoding
early bound regions and also excluding projections when transforming
trait objects' traits into their identities before emitting type checks.
Fix some issues with folded AArch64 features
In #91608 the `fp` feature was removed for AArch64 and folded into the `neon` feature, however disabling the `neon` feature doesn't actually disable the `fp` feature. If my understanding on that thread is correct it should do.
While doing this, I also noticed that disabling some features would disable features that it shouldn't. For instance enabling `sve` will enable `neon`, however, when disabling `sve` it would then also disable `neon`, I wouldn't expect disabling `sve` to also disable `neon`.
cc `@workingjubilee`
Rollup of 6 pull requests
Successful merges:
- #111461 (Fix symbol conflict diagnostic mistakenly being shown instead of missing crate diagnostic)
- #111579 (Also assume wrap-around discriminants in `as` MIR building)
- #111704 (Remove return type sized check hack from hir typeck)
- #111853 (Check opaques for mismatch during writeback)
- #111854 (rustdoc: clean up `settings.css`)
- #111860 (Don't ICE if method receiver fails to unify with `arbitrary_self_types`)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE if method receiver fails to unify with `arbitrary_self_types`
Consider:
```rust
struct Foo(u32);
impl Foo {
fn get<R: Deref<Target=Self>>(self: R) -> u32 {
self.0
}
}
fn main() {
let mut foo = Foo(1);
foo.get::<&Foo>();
}
```
The problem here is that with `arbitrary_self_types`, we're allowed to have a method receiver that mentions generics from the method itself (`fn get<R: Deref<Target=Self>>(self: R)`). Since we don't actually take into account the user-written turbofish generics when doing method lookup (nor do we check that method predicates hold), method probing will happily infer `R = Foo` during the probe. When we later confirm the method, we do use the turbofish'd subst and instead now have that `R = &Foo`. This doesn't unify with the self type we chose during the probe, causing an ICE.
Getting this to work correctly will be difficult. Specifically, we'll need to actually pass in the turbofish generics for the method being probed for and check that the self type unifies considering those generics. This seems like a lot of work, and I'm not actually familiar with the restrictions originally called out for `#![feature(arbitrary_self_types)]`, but I think we should probably instead just deny having receivers that mention (type/const) generics that come from the method itself.
But I mostly just want to turn this ICE into an error, so I'll leave that up for later PRs.
Fixes#111838
Check opaques for mismatch during writeback
Revive #111705.
I realized that we don't need to put any substs in the writeback results since all of the hidden types have already been remapped. See the comment in `compiler/rustc_middle/src/ty/typeck_results.rs`, which should make that clear for other explorers of the codebase.
Additionally, we need to do some diagnostic stashing because the diagnostics we produce during HIR typeck is very poor and we should prefer the diagnostic that comes from MIR, if we have one.
r? `@oli-obk`
Remove return type sized check hack from hir typeck
Remove a bunch of special-cased suggestions when someone returns `-> dyn Trait` that checks for type equality, etc.
This was a pretty complex piece of code that also relied on a hack in hir typeck (see changes to `compiler/rustc_hir_typeck/src/check.rs`), and I'm not convinced that it's necessary to maintain, when all we really need to tell the user is that they should return `-> impl Trait` or `-> Box<dyn Trait>`, depending on their specific use-case.
This is necessary because we may need to move the "return type is sized" check from hir typeck to wfcheck, which does not have access to typeck results. This is a prerequisite for that, and I'm fairly confident that the diagnostics "regressions" here are not a big deal.
[rustc_ty_utils] Treat `drop_in_place`'s *mut argument like &mut when adding LLVM attributes
This resurrects PR #103614, which has sat idle for a while.
This could probably use a new perf run, since we're on a new LLVM version now.
r? `@oli-obk`
cc `@RalfJung`
---
LLVM can make use of the `noalias` parameter attribute on the parameter to `drop_in_place` in areas like argument promotion. Because the Rust compiler fully controls the code for `drop_in_place`, it can soundly deduce parameter attributes on it.
In #103957, Miri was changed to retag `drop_in_place`'s argument as if it was `&mut`, matching this change.
Deal with unnormalized projections when structurally resolving types with new solver
1. Normalize types in `structurally_resolved_type` when the new solver is enabled
2. Normalize built-in autoderef targets in `Autoderef` when the new solver is enabled
3. Normalize-erasing-regions in `resolve_type` in writeback
This is motivated by the UI test provided, which currently fails with:
```
error[E0609]: no field `x` on type `<usize as SliceIndex<[Foo]>>::Output`
--> <source>:9:11
|
9 | xs[0].x = 1;
| ^
```
I'm pretty happy with the approach in (1.) and (2.) and think we'll inevitably need something like this in the long-term, but (3.) seems like a hack to me. It's a *lot* of work to add tons of new calls to every user of these typeck results though (mir build, late lints, etc). Happy to discuss further.
r? `@lcnr`
This was added to control percentage sizes, in
79956b96e8
Now, the only percentage size is [`border-radius`], which is
based on the size of the box itself, not its containing block.
This leaves the property unused.
[`border-radius`]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius
