Dejargonize `subst`
In favor of #110793, replace almost every occurence of `subst` and `substitution` from rustc codes, but they still remains in subtrees under `src/tools/` like clippy and test codes (I'd like to replace them after this)
Fix async closures in CTFE
First commit renames `is_coroutine_or_closure` into `is_closure_like`, because `is_coroutine_or_closure_or_coroutine_closure` seems confusing and long.
Second commit fixes some forgotten cases where we want to handle `TyKind::CoroutineClosure` the same as closures and coroutines.
The test exercises the change to `ValidityVisitor::aggregate_field_path_elem` which is the source of #120946, but not the change to `UsedParamsNeedSubstVisitor`, though I feel like it's not that big of a deal. Let me know if you'd like for me to look into constructing a test for the latter, though I have no idea what it'd look like (we can't assert against `TooGeneric` anywhere?).
Fixes#120946
r? oli-obk cc ``@RalfJung``
compiletest: few naive improvements
Tested on `python x.py --stage=1 t tests/ui/borrowck/ --force-rerun`, see individual commits.
Wall time didn't improved :-) .
Gate PR CI on clippy correctness lints
Implements part of https://github.com/rust-lang/compiler-team/issues/709.
Note that `x.py clippy compiler` also checks the standard library, because it needs to be checked before the compiler. This happens even with `x.py clippy --stage 0`.
Warn on references casting to bigger memory layout
This PR extends the [`invalid_reference_casting`](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#invalid-reference-casting) lint (*deny-by-default*) which currently lint on `&T -> &mut T` casting to also lint on `&(mut) A -> &(mut) B` where `size_of::<B>() > size_of::<A>()` (bigger memory layout requirement).
The goal is to detect such cases:
```rust
let u8_ref: &u8 = &0u8;
let u64_ref: &u64 = unsafe { &*(u8_ref as *const u8 as *const u64) };
//~^ ERROR casting references to a bigger memory layout is undefined behavior
let mat3 = Mat3 { a: Vec3(0i32, 0, 0), b: Vec3(0, 0, 0), c: Vec3(0, 0, 0) };
let mat3 = unsafe { &*(&mat3 as *const _ as *const [[i64; 3]; 3]) };
//~^ ERROR casting references to a bigger memory layout is undefined behavior
```
This is added to help people who write unsafe code, especially when people have matrix struct that they cast to simple array of arrays.
EDIT: One caveat, due to the [`&Header`](https://github.com/rust-lang/unsafe-code-guidelines/issues/256) uncertainty the lint only fires when it can find the underline allocation.
~~I have manually tested all the new expressions that warn against Miri, and they all report immediate UB.~~
r? ``@est31``
Rollup of 11 pull requests
Successful merges:
- #120765 (Reorder diagnostics API)
- #120833 (More internal emit diagnostics cleanups)
- #120899 (Gracefully handle non-WF alias in `assemble_alias_bound_candidates_recur`)
- #120917 (Remove a bunch of dead parameters in functions)
- #120928 (Add test for recently fixed issue)
- #120933 (check_consts: fix duplicate errors, make importance consistent)
- #120936 (improve `btree_cursors` functions documentation)
- #120944 (Check that the ABI of the instance we are inlining is correct)
- #120956 (Clean inlined type alias with correct param-env)
- #120962 (Add myself to library/std review)
- #120972 (fix ICE for deref coercions with type errors)
r? `@ghost`
`@rustbot` modify labels: rollup
Clean inlined type alias with correct param-env
We were cleaning the `hir::Ty` of a type alias item in the param-env of the item that *references* the type alias, and not the alias's own param-env.
Fixes#120954
- improve diagnostics of field uniqueness check and representation check
- simplify the implementation of field uniqueness check
- remove some useless codes and improvement neatness
[docs] Update armv6k-nintendo-3ds platform docs for outdated info
Mostly just fixing links and references to renamed crates, but also updating a bit of outdated info as well.
CC `@Meziu` `@AzureMarker`
Assert that params with the same *index* have the same *name*
Found this bug when trying to build libcore with the new solver, since it will canonicalize two params with the same index into *different* placeholders if those params differ by name.
always run `configure_linker` except for mir-opt tests
`configure_linker` now runs consistently unless it's for mir-opt tests. Previously `!= "check"` condition was causing dirt in the cargo cache between runs of `x anything-but-not-check` and `x check`.
Fixes#120768
cc `@saethlin`
Rollup of 10 pull requests
Successful merges:
- #117740 (Add some links and minor explanatory comments to `std::fmt`)
- #118307 (Remove an unneeded helper from the tuple library code)
- #119242 (Suggest less bug-prone construction of Duration in docs)
- #119449 (Fix `clippy::correctness` in the library)
- #120307 (core: add Duration constructors)
- #120459 (Document various I/O descriptor/handle conversions)
- #120729 (Update mdbook to 0.4.37)
- #120763 (Suggest pattern tests when modifying exhaustiveness)
- #120906 (Remove myself from some review rotations)
- #120916 (Subtree update of ` rust-analyzer`)
r? `@ghost`
`@rustbot` modify labels: rollup
Suggest pattern tests when modifying exhaustiveness
The vast majority of exhaustiveness tests are in `tests/ui/pattern`, this is what I've been using for years. This PR is me telling `x suggest` about that.
cc `@Ezrashaw`
Update mdbook to 0.4.37
This updates mdbook to 0.4.37.
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0437
The primary change is the update to pulldown-cmark which has a large number of markdown parsing changes. There shouldn't be any significant changes to the rendering of any of the books (I have posted some PRs to fix some minor issues to the ones that were affected).
core: add Duration constructors
Add more `Duration` constructors.
Tracking issue: #120301.
These match similar convenience constructors available on both `chrono::Duration` and `time::Duration`.
What's the best ordering for these with respect to the existing constructors?
Allowing the Xcode version to "float" based on whatever default GitHub
selects creates an unreliable environment. When GitHub changes the
default, we can have multiple jobs in the same run using different
versions as it rolls out across machines. It can also cause oscillation
between runs as different machines are used. It also causes
unpredictable timing when the updates happen.
This change helps ensure that the version that is used is pinned. The
downside is that it requires manually bumping the version, and the risk
that if we take too long, older Xcodes will be removed and that will
break the build.
This seems to fix two sporadic errors that have been appearing in CI.
One is an issue with cmake being unable to verify that cmake is able to
build a simple test program. The other is a `invalid r_symbolnum`
linking error when trying to build one of cranelift's tests.
This is intended as a temporary fix until we can figure out how to
resolve those issues.
Adapt `llvm-has-rust-patches` validation to take `llvm-config` into account.
This adapts an assertion that was added in #119556.
The current assertion does not take the `llvm-config` setting into accounts, which does not match the `llvm-has-rust-patches` documentation, which states:
> This would be used in conjunction with either an llvm-config or build.submodules = false.
(It also breaks my workflow: I build LLVM separately, but do have the rust patches applied).
---
**edit:** Originally this PR just removed the assertion, but it now implements the alternative mentioned here:
An alternative fix would be to take `llvm-config` into account in the assertion, but to me the assertion seems to provide little value, thus the simpler fix of just removing it.
cc `@onur-ozkan,` in case I'm missing a reason to keep the assertion.
fix `llvm_out` to use the correct LLVM root
When `download-ci-llvm` is enabled, `llvm_out` ends up with the
error below due to an incorrect path on cross-compilations. This change fixes that.
```sh
failed to execute command: "/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--version"
ERROR: No such file or directory (os error 2)
```
[rustdoc] Correctly generate path for non-local items in source code pages
While browsing some crates using the "jump to def" feature, I realized that a lot of items didn't have a link generated. The reason is because we only cache foreign items if they appear in the documented API. This means that for the others, we need to infer them.
r? ``@notriddle``
