Rustc pull update #2547
Merged
Rustc pull update #2547
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![workflows-rustc-dev-guide[bot]](https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
Revert "Preserve the .debug_gdb_scripts section" rust-lang/rust#143679 introduces a significant build time perf regression for ripgrep. Let's revert it such that we can investigate it without pressure.
Tweak auto trait errors
Make suggestions to remove params and super traits verbose and make spans more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
add nvptx_target_feature Tracking issue: #141468 (nvptx), which is part of #44839 (catch-all arches) The feature gate is `#![feature(nvptx_target_feature)]` This exposes the target features `sm_20` through `sm_120a` [as defined](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.1/llvm/lib/Target/NVPTX/NVPTX.td#L59-L85) by LLVM. Cc: ``````@gonzalobg`````` ``````@rustbot`````` label +O-NVPTX +A-target-feature
implement continue_ok and break_ok for ControlFlow Tracking issue: rust-lang/rust#140266 r? ``````@dtolnay``````
emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching This PR removes special handling of `let`-`else`, so that `StorageLive`s are emitted and `StorageDead`s are scheduled only after pattern-matching has succeeded. This means `StorageDead`s will no longer appear for all of its bindings on the `else` branch (because they're not live yet) and its drops&`StorageDead`s will happen together like they do elsewhere, rather than having all drops first, then all `StorageDead`s. This fixes rust-lang/rust#142056, and is therefore a breaking change. I believe it'll need a crater run and a T-lang nomination/fcp thereafter. Specifically, this makes drop-checking slightly more restrictive for `let`-`else` to match the behavior of other variable binding forms. An alternative approach could be to change the relative order of drops and `StorageDead`s for other binding forms to make drop-checking more permissive, but making that consistent would be a significantly more involved change. r? mir cc `````@dingxiangfei2009````` `````@rustbot````` label +T-lang +needs-crater
…ril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang/rust#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang/rust#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang/rust#143376 and probably also rust-lang/rust#143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`
…szelmann Port `#[should_panic]` to the new attribute parsing infrastructure Ports `#[should_panic]` to the new attribute parsing infrastructure for rust-lang/rust#131229 (comment) r? ```@jdonszelmann```
…items, r=RalfJung Miri: non-deterministic floating point operations in `foreign_items` Part of [rust-lang/miri/#3555](rust-lang/miri#3555 (comment)), this pr does the `foreign_items` work. Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added. Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`. I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as: ``` Returns The sinh functions return sinh x. ``` So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
Mark all deprecation lints in name resolution as deny-by-default and report-in-deps This affects the next lints: - `MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS` - rust-lang/rust#144408 - `LEGACY_DERIVE_HELPERS` - rust-lang/rust#79202 - `PRIVATE_MACRO_USE` - rust-lang/rust#120192 - `OUT_OF_SCOPE_MACRO_CALLS` - rust-lang/rust#144406
Stabilize const TypeId::of fixes rust-lang/rust#77125 # Stabilization report for `const_type_id` ## General design ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? N/A the constness was never RFCed ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. `const_type_id` was kept unstable because we are currently unable to stabilize the `PartialEq` impl for it (in const contexts), so we feared people would transmute the type id to an integer and compare that integer. ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? `TypeId::eq` is not const at this time, and will only become const once const traits are stable. ## Has a Call for Testing period been conducted? If so, what feedback was received? This feature has been unstable for a long time, and most people just worked around it on stable by storing a pointer to `TypeId::of` and calling that at "runtime" (usually LLVM devirtualized the function pointer and inlined the call so there was no real performance difference). A lot of people seem to be using the `const_type_id` feature gate (600 results for the feature gate on github: https://github.com/search?q=%22%23%21%5Bfeature%28const_type_id%29%5D%22&type=code) We have had very little feedback except desire for stabilization being expressed. ## Implementation quality Until these three PRs * rust-lang/rust#142789 * rust-lang/rust#143696 * rust-lang/rust#143736 there was no difference between the const eval feature and the runtime feature except that we prevented you from using `TypeId::of` at compile-time. These three recent PRs have hardened the internals of `TypeId`: * it now contains an array of pointers instead of integers * these pointers at compile-time (and in miri) contain provenance that makes them unique and prevents inspection. Both miri and CTFE will in fact error if you mess with the bits or the provenance of the pointers in any way and then try to use the `TypeId` for an equality check. This also guards against creating values of type `TypeId` by any means other than `TypeId::of` ### Summarize the major parts of the implementation and provide links into the code (or to PRs) N/A see above ### Summarize existing test coverage of this feature Since we are not stabilizing any operations on `TypeId` except for creating `TypeId`s, the test coverage of the runtime implementation of `TypeId` covers all the interesting use cases not in the list below #### Hardening against transmutes * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id2.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id3.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id4.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id5.rs #### TypeId::eq is still unstable * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_cmp_type_id.rs ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? rust-lang/rust#129014 is still unresolved, but it affects more the runtime version of `TypeId` than the compile-time. ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? none ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * `@eddyb` * `@RalfJung` ### Which tools need to be adjusted to support this feature. Has this work been done? N/A ## Type system and execution rules ### What compilation-time checks are done that are needed to prevent undefined behavior? Already covered above. Transmuting types with private fields to expose those fields has always been library UB, but for the specific case of `TypeId` CTFE and Miri will detect it if that is done in any way other than for reconstructing the exact same `TypeId` in another location. ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? N/A ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) N/A ### What updates are needed to the reference/specification? (link to PRs when they exist) Nothing more than what needs to exist for `TypeId` already. ## Common interactions ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? N/A ### What other unstable features may be exposed by this feature? N/A
… r=petrochenkov Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error. Per rust-lang/rust#79813 (comment)
Introduce ModernIdent type to unify macro 2.0 hygiene handling This pr introduce ModernIdent type to unify macro 2.0 hygiene handling 1. Added ModernIdent type. Wraps Ident and automatically calls `normalize_to_macros_2_0()` 2. Unified identifier normalization. Replaced scattered ident.normalize_to_macros_2_0() calls with ModernIdent::new(ident) r? ````@petrochenkov````
…acrum Address libunwind.a inconsistency issues in the bootstrap program We noticed when building rustc multiple time in a roll, some files will not be consistent across the build despite the fact that they are built from same source under the same environment. This patch addresses the inconsistency issue we found on libunwind.a, by sorting the order of the files passed to the linker.
…taxes, r=petrochenkov Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes` Workaround for rust-lang/rust#144588 (comment) Not all suggestions have to be hidden from `cargo fix`, only redundant ones. The redundant ones are already hidden from the user, so the same `tool_only` flag can be used to hide them from `cargo fix`. This way `cargo fix` will be able to correctly apply the fixes, and will apply only the fix that the compiler visibly suggests to the user.
…n,tgross35 Additional tce tests r? `@oli-obk` Adds known-bug tests for LLVM emissions regarding indirect operands for TCE. Also includes a test, `indexer.rs`, referring to function_table behavior described by the RFC. Depends on rust-lang/rust#144232 Closes rust-lang/rust#144293
bootstrap: refactor mingw dist and fix gnullvm Fixes rust-lang/rust#144533 The first two commits are NFC and only clean up the code, paving the way for the third commit. That said, I think they are worthwhile even without that fix - reusing the same function for two different outcomes was confusing. The third commit is the fix for rust-lang/rust#144533, but due to the cross-compilation dance it requires a workaround to find the DLL since that logic really was meant only for Windows builders. That workaround is short-lived and will be removed as soon as gnullvm bootstraps itself.
Stabilize `strict_overflow_ops` Closes rust-lang/rust#118260
Reimplement `print_region` in `type_name.rs`. Broken by rust-lang/rust#144776; this is reachable after all. Fixes rust-lang/rust#144994. The commit also adds a lot more cases to the `type-name-basic.rs`, because it's currently very anaemic. This includes some cases where region omission does very badly; these are marked with FIXME. r? `@fmease`
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to 1beca63. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
bump bootstrap compiler to 1.90 beta There were significantly less `cfg(bootstrap)` and `cfg(not(bootstrap))` this release. Presumably due to the fact that we change the bootstrap stage orderings to reduce the need for them and it was successful 🙏
Rollup of 19 pull requests Successful merges: - rust-lang/rust#137831 (Tweak auto trait errors) - rust-lang/rust#138689 (add nvptx_target_feature) - rust-lang/rust#140267 (implement continue_ok and break_ok for ControlFlow) - rust-lang/rust#143028 (emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching) - rust-lang/rust#143764 (lower pattern bindings in the order they're written and base drop order on primary bindings' order) - rust-lang/rust#143808 (Port `#[should_panic]` to the new attribute parsing infrastructure ) - rust-lang/rust#143906 (Miri: non-deterministic floating point operations in `foreign_items`) - rust-lang/rust#143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps) - rust-lang/rust#144133 (Stabilize const TypeId::of) - rust-lang/rust#144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny) - rust-lang/rust#144439 (Introduce ModernIdent type to unify macro 2.0 hygiene handling) - rust-lang/rust#144473 (Address libunwind.a inconsistency issues in the bootstrap program) - rust-lang/rust#144601 (Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes`) - rust-lang/rust#144650 (Additional tce tests) - rust-lang/rust#144659 (bootstrap: refactor mingw dist and fix gnullvm) - rust-lang/rust#144682 (Stabilize `strict_overflow_ops`) - rust-lang/rust#145026 (Update books) - rust-lang/rust#145033 (Reimplement `print_region` in `type_name.rs`.) - rust-lang/rust#145040 (rustc-dev-guide subtree update) Failed merges: - rust-lang/rust#143857 (Port #[macro_export] to the new attribute parsing infrastructure) r? `@ghost` `@rustbot` modify labels: rollup
Clippy subtree update r? `@Manishearth` Cargo.lock update due to clippy version bump
Pass -Werror when building the LLVM wrapper cc rust-lang/rust#109712
Implement `stability_implications` without a visitor. Since rust-lang/rust#143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
…r=fmease,GuillaumeGomez Don't emit `rustdoc::broken_intra_doc_links` for GitHub-flavored Markdown admonitions like `[!NOTE]` fixes rust-lang/rust#141866
Support using #[unstable_feature_bound] on trait This is needed to unblock rust-lang/rust#145095 r? ```````@BoxyUwU```````
Document compiler and stdlib in stage1 in `pr-check-2` CI job This restores the original behavior pre-rust-lang/rust#145011 (I thought that stage 2 makes more sense here, but it made the job ~30m slower, which is bad). Let's see what will be the "new" duration, it should be ~55 minutes. r? ```````@jieyouxu```````
Make explicit guarantees about `Vec`’s allocator This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`. Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
…ore, r=davidtwco compiler: Allow `extern "interrupt" fn() -> !` While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited. - Fixes rust-lang/rust#143072
Fix tail calls to `#[track_caller]` functions We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls. The only way to achieve this that I can see is: - we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented) - tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr) Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated) Additionally I added a lint, although I don't think it's strictly necessary. Alternative to rust-lang/rust#144762 (and thus closes rust-lang/rust#144762) Fixes rust-lang/rust#144755
E0793: Clarify that it applies to unions as well pick up inactive PR: rust-lang/rust#131472 Also: Adjust the language slightly to be more consistent with other similar messages (was created instead of got created). Add a short section on union. Add an example line showing referencing a field in a packed struct is safe if the field's type isn't more strictly aligned than the pack. r? compiler-errors
…, r=Mark-Simulacrum Fix description of unsigned `checked_exact_div` Like its signed counterpart, this function does not panic. Also, fix the examples to document how it returns Some/None.
Couple of minor cleanups
strip prefix of temporary file names when it exceeds filesystem name length limit When doing lto, rustc generates filenames that are concatenating many information. In the case of this testcase, it is concatenating crate name and rust file name, plus some hash, and the extension. In some other cases it will concatenate even more information reducing the maximum effective crate name to about 110 chars on linux filesystems where filename max length is 255 This commit is ensuring that the temporary file names are limited in size, while still reasonably ensuring the unicity (with hashing of the stripped part) Fix: rust-lang/rust#49914
Tail call diagnostics to include lifetime info Fixes rust-lang/rust#144957 r? ```@WaffleLapkin``` ```@compiler-errors```
resolve: Introduce `RibKind::Block` to avoid confusing module items, blocks with items, and blocks without items. Addresses rust-lang/rust#143141 (comment) and rust-lang/rust#143141 (comment). A couple of related cleanups are also added on top.
llvm: Accept new LLVM lifetime format In llvm/llvm-project#150248 LLVM removed the size parameter from the lifetime format. Tolerate not having that size parameter.
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 18 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-svg v0.1.9 -> v0.1.10
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating camino v1.1.10 -> v1.1.11
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating cxx v1.0.161 -> v1.0.166
Updating cxx-build v1.0.161 -> v1.0.166
Updating cxxbridge-cmd v1.0.161 -> v1.0.166
Updating cxxbridge-flags v1.0.161 -> v1.0.166
Updating cxxbridge-macro v1.0.161 -> v1.0.166
Updating derive-where v1.5.0 -> v1.6.0
Updating hashbrown v0.15.4 -> v0.15.5
Updating indenter v0.3.3 -> v0.3.4
Updating rustversion v1.0.21 -> v1.0.22
Updating scratch v1.0.8 -> v1.0.9
Updating zerovec v0.11.2 -> v0.11.4
note: pass `--verbose` to see 36 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating hashbrown v0.15.4 -> v0.15.5
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 10 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating cc v1.2.31 -> v1.2.32
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating clap_complete v4.5.55 -> v4.5.56
Updating hashbrown v0.15.4 -> v0.15.5
Updating rustversion v1.0.21 -> v1.0.22
Updating zerovec v0.11.2 -> v0.11.4
```
Minor `[const]` tweaks Self explanatory
…=alexcrichton fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute Resolves rust-lang/rust#140174 r? ```@alexcrichton``` try-job: `test-various*`
…r=petrochenkov Resolve the prelude import in `build_reduced_graph` This pr tries to resolve the prelude import at the `build_reduced_graph` stage. Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493. r? petrochenkov
Make std use the edition 2024 prelude This seem to have been overlooked in <rust-lang/rust#138162>
Do not ICE on private type in field of unresolved struct Fix rust-lang/rust#145367.
Add `FnContext` in parser for diagnostic Fixes rust-lang/rust#144968 Inspired by rust-lang/rust#144968 (comment), I implemented `FnContext` to indicate whether a function should have a self parameter, for example, whether the function is a trait method, whether it is in an impl block. And I removed the outdated note. I made two commits to show the difference. cc ``@estebank`` ``@djc`` r? compiler
[rustdoc] Revert "rustdoc search: prefer stable items in search results" Reverts rust-lang/rust#141658 and reverts rust-lang/rust#145349. Reopens rust-lang/rust#138067. r? ```@fmease```
coverage: Remove intermediate data structures from mapping creation The data structures in `coverage::mappings` were historically very useful for isolating the details of mapping-extraction from the details of how coverage mappings are stored in MIR. But because of various changes that have taken place over time, they now provide little value, and cause difficulty for the coordinated changes that will be needed for introducing expansion mapping support. In the future, the pendulum might eventually swing back towards these being useful again, but we can always reintroduce suitable intermediate data structures if and when that happens. For now, the simplicity of not having this intermediate layer is a higher priority. There should be no changes to compiler output.
Rollup of 21 pull requests Successful merges: - rust-lang/rust#118087 (Add Ref/RefMut try_map method) - rust-lang/rust#122661 (Change the desugaring of `assert!` for better error output) - rust-lang/rust#142640 (Implement autodiff using intrinsics) - rust-lang/rust#143075 (compiler: Allow `extern "interrupt" fn() -> !`) - rust-lang/rust#144865 (Fix tail calls to `#[track_caller]` functions) - rust-lang/rust#144944 (E0793: Clarify that it applies to unions as well) - rust-lang/rust#144947 (Fix description of unsigned `checked_exact_div`) - rust-lang/rust#145004 (Couple of minor cleanups) - rust-lang/rust#145005 (strip prefix of temporary file names when it exceeds filesystem name length limit) - rust-lang/rust#145012 (Tail call diagnostics to include lifetime info) - rust-lang/rust#145065 (resolve: Introduce `RibKind::Block`) - rust-lang/rust#145120 (llvm: Accept new LLVM lifetime format) - rust-lang/rust#145189 (Weekly `cargo update`) - rust-lang/rust#145235 (Minor `[const]` tweaks) - rust-lang/rust#145275 (fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute) - rust-lang/rust#145322 (Resolve the prelude import in `build_reduced_graph`) - rust-lang/rust#145331 (Make std use the edition 2024 prelude) - rust-lang/rust#145369 (Do not ICE on private type in field of unresolved struct) - rust-lang/rust#145378 (Add `FnContext` in parser for diagnostic) - rust-lang/rust#145389 ([rustdoc] Revert "rustdoc search: prefer stable items in search results") - rust-lang/rust#145392 (coverage: Remove intermediate data structures from mapping creation) r? `@ghost` `@rustbot` modify labels: rollup
…=BoxyUwU ignore head usages from ignored candidates Fixes rust-lang/trait-system-refactor-initiative#210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns. The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result. We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability. It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
`apply_member_constraints`: fix placeholder check Checking whether the member region is *an existential region from a higher universe* is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before rust-lang/rust#140466. I've encountered this issue separately while working on rust-lang/rust#139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile ```rust trait Proj<'a> { type Assoc; } impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F { type Assoc = (); } fn is_proj<F: for<'a> Proj<'a>>(f: F) {} fn define<'a>() -> impl Sized + use<'a> { // This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`. // 'unconstrained_b is an inference variable from a higher universe as it gets // created inside of the binder of `F: for<'a> Proj<'a>`. This previously // caused us to not apply member constraints. We now do, constraining // it to `'a`. is_proj(define::<'a>); &() } fn main() {} ``` This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc rust-lang/rust#140569/rust-lang/rust#142073. However, as we always skipped these member regions in `apply_member_constraints` the skipped region is guaranteed to cause an error in `check_member_constraints` later on.
Revert "Partially outline code inside the panic! macro". This reverts rust-lang/rust#115670 Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
const-eval: full support for pointer fragments This fixes rust-lang/const-eval#72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in rust-lang/rust#137280. For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics: ```rust use std::{mem::{self, MaybeUninit}, ptr}; type Byte = MaybeUninit<u8>; const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) { let mut i = 0; while i < n { *dst.add(i) = *src.add(i); i += 1; } } const _MEMCPY: () = unsafe { let ptr = &42; let mut ptr2 = ptr::null::<i32>(); // Copy from ptr to ptr2. memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>()); assert!(*ptr2 == 42); }; ``` What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again. We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^ This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to rust-lang/unsafe-code-guidelines#558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
Print regions in `type_name`. Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`. Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo. `c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter. The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions. Fixes rust-lang/rust#145168. r? `@lcnr`
This updates the rust-version file to 425a9c0a0e365c0b8c6cfd00c2ded83a73bed9a0.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 425a9c0a0e365c0b8c6cfd00c2ded83a73bed9a0 Filtered ref: 26b9fd2 This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.