-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #93956
Rollup of 9 pull requests #93956
Conversation
- Implement lowering for subtype goals - Use correct lang item for Generator trait - Use `lower_into` for lowering `ty::Variance`
This is required to avoid creating large numbers of universes from each Chalk query, while still having enough universe information for lifetime errors.
It is a leftover from before the introduction of rustc_interface
This ensures that it is called even when run_in_thread_pool_with_globals is avoided and reduces code duplication between the parallel and non-parallel version of run_in_thread_pool_with_globals
The only difference between the default and rustc_interface set version is that the default accesses the source map from SESSION_GLOBALS while the rustc_interface version accesses the source map from the global TyCtxt. SESSION_GLOBALS is always set while running the compiler while the global TyCtxt is not always set. If the global TyCtxt is set, it's source map is identical to the one in SESSION_GLOBALS
canonicalize_chalk_query -> canonicalize_query_preserving_universes
Co-authored-by: Mark Rousskov <[email protected]>
…mulacrum make `Instant::{duration_since, elapsed, sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects, especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors, but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive, i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see rust-lang#83093 for benchmarks, the worst-case overhead is > 100x. The other is sporadic panics on specific, rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead, fine-grained timestamps are needed - such as syscall tracing, performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes), hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes rust-lang#84448 closes rust-lang#86470
… r=oli-obk More informative error message for E0015 Helps with rust-lang#92380
…niverses, r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`
More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest, I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option<u32> { Some(x * x) } fn nope(_: u32) -> Option<u32> { None } assert_eq!(Some(2).and_then(sq).and_then(sq), Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope), None); assert_eq!(Some(2).and_then(nope).and_then(sq), None); assert_eq!(None.and_then(sq).and_then(sq), None); ``` Current example: - does not demonstrate that `and_then` converts `Option<T>` to `Option<U>` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.
…rk-Simulacrum bootstrap.py: Suggest disabling download-ci-llvm option if url fails to download I got an error when trying to build the compiler using an old commit, and it turns out it was because the option `download-ci-llvm` was implicitly set to true. So this pull request tries to add a help message for other people that may run into the same problem. To reproduce my error: ``` git checkout 8d7707f ./x.py test [...] spurious failure, trying again downloading https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz curl: (22) The requested URL returned error: 404 failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmp8g13rb4n https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz Build completed unsuccessfully in 0:00:46 ``` This is my `config.toml`: ``` # Includes one of the default files in src/bootstrap/defaults profile = "compiler" changelog-seen = 2 [rust] debug = true ``` To reproduce an error with this branch: Change line 618 of bootstrap.py to ``` url = "rustc-builds-error404/{}".format(llvm_sha) ``` Delete llvm and cached tarball, and set `llvm.download-ci-llvm=true` in config.toml. ``` ./x.py test [...] spurious failure, trying again downloading https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz curl: (22) The requested URL returned error: 404 failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmpesl1ydvo https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz error: failed to download llvm from ci help: old builds get deleted after a certain time help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml: [llvm] download-ci-llvm = false Build completed unsuccessfully in 0:00:01 ``` Regarding the implementation, I expected to be able to use a try/catch block in `_download_ci_llvm`, but the `run` function calls `sys.exit` instead of raising an exception so that's not possible. Also, suggestions for better wording of the help message are welcome.
…Mark-Simulacrum Stabilise inherent_ascii_escape (FCP in rust-lang#77174) Implements rust-lang#77174, which completed its FCP. This does *not* deprecate any existing methods or structs, as that is tracked in rust-lang#93887. That stated, people should prefer using `u8::escape_ascii` to `std::ascii::escape_default`.
add link to format_args! when mention it in docs close rust-lang#93904
Couple of driver cleanups * Remove the `RustcDefaultCalls` struct, which hasn't been necessary since the introduction of `rustc_interface`. * Move the `setup_callbacks` call around for a tiny code deduplication. * Remove the `SPAN_DEBUG` global as it isn't actually necessary.
…acrum Don't relabel to a team if there is already a team label Should prevent cases like rust-lang#93628, where teams have been manually assigned, but changes are pushed. We give up adding new labels on *new* changes; but I feel like that is less frequent. r? `@Mark-Simulacrum`
@bors r+ rollup=never p=9 |
📌 Commit 20ea5c5 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9a60099): comparison url. Summary: This benchmark run did not return any relevant results. 38 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
Instant::{duration_since, elapsed, sub}
saturating and remove workarounds #89926 (makeInstant::{duration_since, elapsed, sub}
saturating and remove workarounds)Option::and_then
&Result::and_then
#93851 (More practical examples forOption::and_then
&Result::and_then
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup