Don't do cc detection for synthetic targets
Fixes https://github.com/rust-lang/rust/issues/125365
Synthetic targets only exist for mir-opt tests, and the mir-opt test suite is in general designed to avoid any use of a C compiler. We don't need to do CC detection. It's unclear to me how this code didn't cause issues before.
add pull request template asking for relevant tracking issues
As mentioned at RustNation, I would like to remind PR authors to link to relevant tracking issues when opening PRs as it is otherwise very easy to forget doing so.
There's a certain amount of conflict between making the template as small as possible while still being clear for new contributors. I am very much open to changes here but really want to try this out.
Also unsure how much formal buy-in we need here. Maybe merge this pinging t-compiler and t-libs, and then ask how people feel about this on zulip in a few weeks?
r? `@davidtwco`
Fix incorrect suggestion for undeclared hrtb lifetimes in where clauses.
For poly-trait-ref like `for<'a> Trait<T>` in `T: for<'a> Trait<T> + 'b { }`.
We should merge the hrtb lifetimes: existed `for<'a>` and suggestion `for<'b>` or will get err: [E0316] nested quantification of lifetimes
fixes#122714
Relax restrictions on multiple sanitizers
Most combinations of LLVM sanitizers are legal-enough to enable simultaneously. This change will allow simultaneously enabling ASAN and shadow call stacks on supported platforms.
I used this python script to generate the mutually-exclusive sanitizer combinations:
```python
#!/usr/bin/python3
import subprocess
flags = [
["-fsanitize=address"],
["-fsanitize=leak"],
["-fsanitize=memory"],
["-fsanitize=thread"],
["-fsanitize=hwaddress"],
["-fsanitize=cfi", "-flto", "-fvisibility=hidden"],
["-fsanitize=memtag", "--target=aarch64-linux-android", "-march=armv8a+memtag"],
["-fsanitize=shadow-call-stack"],
["-fsanitize=kcfi", "-flto", "-fvisibility=hidden"],
["-fsanitize=kernel-address"],
["-fsanitize=safe-stack"],
["-fsanitize=dataflow"],
]
for i in range(len(flags)):
for j in range(i):
command = ["clang++"] + flags[i] + flags[j] + ["-o", "main.o", "-c", "main.cpp"]
completed = subprocess.run(command, stderr=subprocess.DEVNULL)
if completed.returncode != 0:
first = flags[i][0][11:].replace('-', '').upper()
second = flags[j][0][11:].replace('-', '').upper()
print(f"(SanitizerSet::{first}, SanitizerSet::{second}),")
```
Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS
Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance).
The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute).
That we've been overly cautious here has also been noted by `@thomcc` in https://github.com/rust-lang/rust/pull/117910#issuecomment-1903372350.
r? `@workingjubilee`
`@rustbot` label O-apple
Add opt-for-size core lib feature flag
Adds a feature flag to the core library that enables the possibility to have smaller implementations for certain algorithms.
So far, the core lib has traded performance for binary size. This is likely what most people want since they have big simd-capable machines. However, people on small machines, like embedded devices, don't enjoy the potential speedup of the bigger algorithms, but do have to pay for them. These microcontrollers often only have 16-1024kB of flash memory.
This PR is the result of some talks with project members like `@Amanieu` at RustNL.
There are some open questions of how this is eventually stabilized, but it's a similar question as with the existing `panic_immediate_abort` feature.
Speaking as someone from the embedded side, we'd rather have this unstable for a while as opposed to not having it at all. In the meantime we can try to use it and also add additional PRs to the core lib that uses the feature flag in areas where we find benefit.
Open questions from my side:
- Is this a good feature name?
- `panic_immediate_abort` is fairly verbose, so I went with something equally verbose
- It's easy to refactor later
- I've added the feature to `std` and `alloc` as well as they might benefit too. Do we agree?
- I expect these to get less usage out of the flag since most size-constraint projects don't use these libraries often.
Refactor documentation for Apple targets
Refactor the documentation for Apple targets in `rustc`'s platform support page to make it clear what the supported OS version is and which environment variables are being read (`*_DEPLOYMENT_TARGET` and `SDKROOT`). This fixes https://github.com/rust-lang/rust/issues/124215.
Note that I've expanded the `aarch64-apple-ios-sim` maintainers `@badboy` and `@deg4uss3r` to include being maintainer of all `*-apple-ios-*` targets. If you do not wish to be so, please state that, then I'll explicitly note that in the docs.
Additionally, I've added myself as co-maintainer of most of these targets.
r? `@thomcc`
I think the documentation you've previously written on tvOS is great, have mostly modified it to have a more consistent formatting with the rest of the Apple target.
I recognize that there's quite a few changes here, feel free to ask about any of them!
---
CC `@simlay` `@Nilstrieb`
`@rustbot` label O-apple
Add `IntoIterator` for `Box<[T]>` + edition 2024-specific lints
* Adds a similar method probe opt-out mechanism to the `[T;N]: IntoIterator` implementation for edition 2021.
* Adjusts the relevant lints (shadowed `.into_iter()` calls, new source of method ambiguity).
* Adds some tests.
* Took the liberty to rework the logic in the `ARRAY_INTO_ITER` lint, since it was kind of confusing.
Based mostly off of #116607.
ACP: rust-lang/libs-team#263
References #59878
Tracking for Rust 2024: https://github.com/rust-lang/rust/issues/123759
Crater run was done here: https://github.com/rust-lang/rust/pull/116607#issuecomment-1770293013
Consensus afaict was that there is too much breakage, so let's do this in an edition-dependent way much like `[T; N]: IntoIterator`.
Follow-up fixes to `report_return_mismatched_types`
Some renames, simplifications, fixes, etc. Follow-ups to #123804. I don't think it totally disentangles this code, but it does remove some of the worst offenders on the "I am so confused" scale (e.g. `get_node_fn_decl`).
Uplift `RegionVid`, `TermKind` to `rustc_type_ir`, and `EagerResolver` to `rustc_next_trait_solver`
- Uplift `RegionVid`. This was complicated due to the fact that we implement `polonius_engine::Atom` for `RegionVid` -- but I just separated that into `PoloniusRegionVid`, and added `From`/`Into` impls so it can be defined in `rustc_borrowck` separately. Coherence 😵
- Change `InferCtxtLike` to expose `opportunistically_resolve_{ty,ct,lt,int,float}_var` so that we can uplift `EagerResolver` for use in the canonicalization methods.
- Uplift `TermKind` much like `GenericArgKind`
All of this is miscellaneous dependencies for making more `EvalCtxt` methods generic.
switch to the default implementation of `write_vectored`
HermitOS doesn't support write_vectored and switch to the default implementation of `write_vectored`.
Update books
## rust-lang/book
8 commits in bebcf527e67755a989a1739b7cfaa8f0e6b30040..5e9051f71638aa941cd5dda465e25c61cde9594f
2024-05-16 14:58:56 UTC to 2024-05-07 23:58:22 UTC
- Convert ch01-03-hello-cargo.md Listing 1-2 using `<Listing>` (rust-lang/book#3924)
- infra: fix rendering bug in mdbook-trpl-note (rust-lang/book#3925)
- infra: support `Listing`s without `file-name` (rust-lang/book#3920)
- Add a `<Listing>` preprocessor (rust-lang/book#3918)
- Update explanation according to code listing (rust-lang/book#3916)
- infra: run package tests (rust-lang/book#3915)
- Fix workspace behavior by excluding `listings` (rust-lang/book#3914)
- Backport changes to chapter 8 (rust-lang/book#3913)
## rust-embedded/book
1 commits in 17842ebb050f62e40a4618edeb8e8ee86e758707..dd962bb82865a5284f2404e5234f1e3222b9c022
2024-05-17 23:43:59 UTC to 2024-05-17 23:43:59 UTC
- 'llvm-tools-preview' component is now named 'llvm-tools' (rust-embedded/book#372)
## rust-lang/reference
2 commits in 51817951d0d213a0011f82b62aae02c3b3f2472e..e356977fceaa8591c762312d8d446769166d4b3e
2024-05-10 12:49:15 UTC to 2024-05-07 13:32:57 UTC
- Document inline const/const block expression (rust-lang/reference#1295)
- patterns: include yet unstable exclusive range patterns (rust-lang/reference#1484)
## rust-lang/rust-by-example
7 commits in 229ad13b64d919b12e548d560f06d88963b25cd3..20482893d1a502df72f76762c97aed88854cdf81
2024-05-20 14:36:21 UTC to 2024-05-14 16:17:03 UTC
- Clarify interchangability for From and Into (rust-lang/rust-by-example#1851)
- Update ja.po based on the latest master (rust-lang/rust-by-example#1850)
- Add explicit section link (rust-lang/rust-by-example#1847)
- Adjust translation build on CI (rust-lang/rust-by-example#1849)
- Update mdbook version in CI (rust-lang/rust-by-example#1848)
- Fix some broken links in ja.po (rust-lang/rust-by-example#1844)
- Fix an external link to absolute (rust-lang/rust-by-example#1842)
## rust-lang/rustc-dev-guide
8 commits in 2d1947ff34d50ca46dfe242ad75531a4c429bb52..b6d4a4940bab85cc91eec70cc2e3096dd48da62d
2024-05-17 17:04:58 UTC to 2024-05-09 13:22:03 UTC
- Add a high level explanation of early/late bound params (rust-lang/rustc-dev-guide#1982)
- Fix broken link to "Lowering" (rust-lang/rustc-dev-guide#1981)
- Broken link fix (rust-lang/rustc-dev-guide#1980)
- Add note about how to pick up abandoned PRs (rust-lang/rustc-dev-guide#1977)
- Toc here is overkill (rust-lang/rustc-dev-guide#1976)
- Link to lint `L-*` labels (rust-lang/rustc-dev-guide#1975)
- Update the rustc_interface examples for current rustc (rust-lang/rustc-dev-guide#1974)
- Edit `Parameter Environments`'s url as it has been edited in #1953 (rust-lang/rustc-dev-guide#1973)
track cycle participants per root
The search graph may have multiple roots, e.g. in
```
A :- B
B :- A, C
C :- D
D :- C
```
we first encounter the `A -> B -> A` cycle which causes `A` to be a root. We then later encounter the `C -> D -> C` cycle as a nested goal of `B`. This cycle is completely separate and `C` will get moved to the global cache. This previously caused us to use `[B, D]` as the `cycle_participants` for `C` and `[]` for `A`.
split off from #125167 as I would like to merge this change separately and will rebase that PR on top of this one. There is no test for this issue and I don't quite know how to write one. It is probably worth it to generalize the search graph to enable us to write unit tests for it.
r? `@compiler-errors`
