Don't skip mir typeck if body has errors
Comment says:
```
// if verifier failed, don't do further checks to avoid ICEs
```
But there are no ICEs to be found. The comment is quite old, so perhaps something fixed it... maybe because the MIR typechecker is delaying span bugs rather than panicking via eager bugs? IDK
I'm generally inclined to fix the ICEs themselves that were to arise from this, rather than just totally skipping large parts of the compiler that have impacts on downstream logic (namely, our opaque type results are affected). Anyways, this happens on the error path, so it shouldn't really matter.
Fixes this hack: https://github.com/rust-lang/rust/pull/111853/files#r1201501540
Work around `rust-analyzer` false-positive type errors
rust-analyzer incorrectly reports two type errors in `debug.rs`:
> expected &dyn Display, found &i32
> expected &dyn Display, found &i32
This is due to a known bug in r-a: (https://github.com/rust-lang/rust-analyzer/issues/11847).
In these particular cases, changing `&0` to `&0i32` seems to be enough to avoid the bug.
Preprocess and cache dominator tree
Preprocessing dominators has a very strong effect for https://github.com/rust-lang/rust/pull/111344.
That pass checks that assignments dominate their uses repeatedly. Using the unprocessed dominator tree caused a quadratic runtime (number of bbs x depth of the dominator tree).
This PR also caches the dominator tree and the pre-processed dominators in the MIR cfg cache.
Rebase of https://github.com/rust-lang/rust/pull/107157
cc `@tmiasko`
Don't assume that `-Bdynamic` is the default linker mode
In particular this is false when passing `-static` or `-static-pie` to the linker, which changes the default to `-Bstatic`. This PR ensures we explicitly initialize the correct mode when we first need it.
Rollup of 5 pull requests
Successful merges:
- #111861 (Don't ICE on return-type notation when promoting trait preds to associated type bounds)
- #111864 (Always require closure parameters to be `Sized`)
- #111870 (Rename `traits_in_crate` query to `traits`)
- #111880 (Don't ICE when computing PointerLike trait when region vars are in param-env)
- #111887 (Add regression tests for pretty-printing inherent projections)
r? `@ghost`
`@rustbot` modify labels: rollup
Always require closure parameters to be `Sized`
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.
`@rustbot` label A-closures F-unsized_fn_params
I find that these structs obfuscate the code. Removing them and just
passing the individual fields around makes the `Partition` method
signatures a little longer, but makes the data flow much clearer. E.g.
- `codegen_units` is mutable all the way through.
- `codegen_units`'s length is changed by `merge_codegen_units`, but only
the individual elements are changed by `place_inlined_mono_items` and
`internalize_symbols`.
- `roots`, `internalization_candidates`, and `mono_item_placements` are
all immutable after creation, and all used by just one of the four
methods.
Three of the four methods in `DefaultPartitioning` are defined in
`default.rs`. But `merge_codegen_units` is defined in a separate module,
`merging`, even though it's less than 100 lines of code and roughly the
same size as the other three methods. (Also, the `merging` module
currently sits alongside `default`, when it should be a submodule of
`default`, adding to the confusion.)
In #74275 this explanation was given:
> I pulled this out into a separate module since it seemed like we might
> want a few different merge algorithms to choose from.
But in the three years since there have been no additional merging
algorithms, and there is no mechanism for choosing between different
merging algorithms. (There is a mechanism,
`-Zcgu-partitioning-strategy`, for choosing between different
partitioning strategies, but the merging algorithm is just one piece of
a partitioning strategy.)
This commit merges `merging` into `default`, making the code easier to
navigate and read.
Update cargo
10 commits in 09276c703a473ab33daaeb94917232e80eefd628..64fb38c97ac4d3a327fc9032c862dd28c8833b17
2023-05-16 21:43:35 +0000 to 2023-05-23 18:53:23 +0000
- Consider rust-version when selecting packages for cargo add (rust-lang/cargo#12078)
- fix(lints): Switch to -Zlints so stable projects can experiment (rust-lang/cargo#12168)
- Automatically inherit workspace fields when running cargo new/init (rust-lang/cargo#12069)
- ci: check if any version bump needed for member crates (rust-lang/cargo#12126)
- feat: `lints` feature (rust-lang/cargo#12148)
- fix: pass `-C debuginfo` after weakening if explicitly set (rust-lang/cargo#12165)
- Tweak build help to clarify role of --bin (rust-lang/cargo#12157)
- fix: Pass CI on nightly (rust-lang/cargo#12160)
- docs(source): doc comments for Source and its impls (rust-lang/cargo#12159)
- docs(source): doc comments for `Source` and friends (rust-lang/cargo#12153)
r? `@ghost`
CFI: Fix encode_region: unexpected ReEarlyBound(0, 'a)
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.
Update books
## rust-embedded/book
1 commits in d9eb4c3f75435b008881062ffa77bf0d1527b37d..f2aed2fe8e9f55508c86ba3aa4b6789b18a08a22
2023-05-12 12:26:37 UTC to 2023-05-12 12:26:37 UTC
- Add link to Comprehensive Rust 🦀 (rust-embedded/book#354)
## rust-lang/nomicon
2 commits in b5f7500fc40775096c2bbd204eae096612cf9047..b5f018fb5930cb733b0a8aaf2eed975d4771e74d
2023-05-19 18:10:25 UTC to 2023-05-14 20:22:16 UTC
- Expand unbounded lifetime example code and improve wording (rust-lang/nomicon#408)
- Update to 2021 edition (rust-lang/nomicon#410)
## rust-lang/reference
5 commits in 28dc0f3576b55f5e57c5d6e65cd68ba3161e9fd5..553d99b02a53b4133a40d5bd2e19958c67487c00
2023-05-22 10:50:07 UTC to 2023-05-10 01:54:07 UTC
- Update raw-dylib documentation for stabilization (rust-lang/reference#1345)
- fix a typo (rust-lang/reference#1359)
- fixed minor error in a comment that annotated output of a proc macro (rust-lang/reference#1358)
- Fix example code in `impl` docs (rust-lang/reference#1360)
- Add documentation for debugger_visualizer attribute (rust-lang/reference#1335)
## rust-lang/rustc-dev-guide
4 commits in 28dbeaf5c44bc7f5111ad412e99f2d7c5cec6c90..f1e637883fafeb83bdd5906ee7f467e4d35b7337
2023-05-18 02:44:05 UTC to 2023-05-11 09:59:23 UTC
- Add note about shell completion scripts (rust-lang/rustc-dev-guide#1686)
- filter out S-blocked issues in the "Getting Started" search (rust-lang/rustc-dev-guide#1687)
- Rename InstCombine to InstSimplify (rust-lang/rustc-dev-guide#1684)
- Use unpretty for debugging Hir (rust-lang/rustc-dev-guide#1685)
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`
