Automatic Rustup#3755
Merged
Merged
Conversation
minor: Sync from rust
Bootstrap command refactoring: port remaining commands with access to `Build` (step 6) Continuation of rust-lang/rust#127450. This PR ports commands in bootstrap that can easily get access to `Build(er)` to `BootstrapCommand`. After this PR, everything that can access `Build(er)` should be using the new API. Statistics of `bootstrap` code (ignoring `src/bin/<shims>`) after this PR: ``` 7 usages of `Command::new` 69 usages of `command()` (new API) - out of that: 16 usages of `as_command_mut()` (new API, but accesses the inner command) ``` Tracking issue: rust-lang/rust#126819 r? `@onur-ozkan`
Subtree update of `rust-analyzer` r? `@ghost`
Migrate `std-core-cycle`, `obey-crate-type-flag`, `mixing-libs` and `issue-18943` `run-make` tests to `rmake.rs` Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). try-job: x86_64-apple-1 try-job: x86_64-msvc try-job: aarch64-gnu
maintain the given order on step execution Previously step execution disregarded the CLI order and this change executes the given steps in the order specified on CLI. For example, running `x $kind a b c` will execute `$kind` step for `a`, then `b`, then `c` crates in the specified order. Fixes #126165 cc `@matthiaskrgr`
Windows: Use futex implementation for `Once`
Keep the queue implementation for win7.
Inspired by PR #121956
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Fix ambiguous cases of multiple & in elided self lifetimes This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime. ## The old rules (copied from [this comment](rust-lang/rust#117967 (comment))) Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types. Here's how: * If the first parameter is called self then we search that parameter using "`self` search rules", below * If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below (In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.) ### `self` search rules This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](rust-lang/rust#117715 (comment)) already. The code: 1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see) 2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes 3. If there's exactly one such unique lifetime candidate found, we return this lifetime. ### Regular parameter search rules 1. Find all the lifetimes in each parameter, including implicit, explicit etc. 2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime. ## The new rules There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now: 1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1] 2. Keep a record of: * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk 4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision). 5. If there's one lifetime found, we return the lifetime. 6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used). [^1]: this prevents us from considering lifetimes from inside of the self-type ## Examples that were accepted before and will now be rejected ```rust fn a(self: &Box<&Self>) -> &u32 fn b(self: &Pin<&mut Self>) -> &String fn c(self: &mut &Self) -> Option<&Self> fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg ``` ### Examples that change the elided lifetime ```rust fn e(self: &mut Box<Self>, arg: &usize) -> &usize // ^ new ^ previous ``` ## Examples that were rejected before and will now be accepted ```rust fn f(self: &Box<Self>) -> &u32 ``` --- *edit: old PR description:* ```rust struct Concrete(u32); impl Concrete { fn m(self: &Box<Self>) -> &u32 { &self.0 } } ``` resulted in a confusing error. ```rust impl Concrete { fn n(self: &Box<&Self>) -> &u32 { &self.0 } } ``` resulted in no error or warning, despite apparent ambiguity over the elided lifetime. Fixes rust-lang/rust#117715
interpret: add sanity check in dyn upcast to double-check what codegen does For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.) This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path. r? ``@oli-obk``
Improve error when a compiler/library build fails in `checktools.sh` Suggested by ``@RalfJung`` [here](rust-lang/rust#127869 (comment)). `x86_64-gnu-tools` should take ~45 minutes, let's see if this doesn't regress it. r? ``@onur-ozkan``
Cleanup dll/exe filename calculations in `run_make_support` Use `std::env::consts` constants since now we have access to them (unlike in Makefiles!) ^^ cc `@bzEq` (this is one of the places in our test suites that tries to compute e.g. dylib extension; using `std::env::consts::DLL_EXTENSION` should correctly return `a` for AIX) r? `@fmease` (thank you for the suggestion in rust-lang/rust#127760 (comment), this also improves correctness for the support library!) try-job: aarch64-apple try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc try-job: x86_64-gnu-llvm-18
Fix display of logo "border" Before:  After:  r? `@notriddle`
…it-debuginfo, r=jieyouxu Disable run-make/split-debuginfo test for RISC-V 64 Together with `@Hoverbear,` we've been improving the state of the riscv64gc-unknown-linux-gnu target. This is in relation to rust-lang/rust#125220 where `tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs` was disabled for RISC-V 64 in that another test, `tests/run-make/split-debuginfo` also needs to be disabled due to llvm/llvm-project#56642 and the changes made in rust-lang/rust#120518. This test appears to be a host test, not a target test, so it isn't seen failing in rust-lang/rust#126641, however, we are in the process of testing host tools for riscv64-gc-unknown-linux-gnu so this test has now been noticed to be a problem.
Rollup of 7 pull requests Successful merges: - #112328 (Feat. adding ext that returns change_time) - #126199 (Add `isqrt` to `NonZero<uN>`) - #127856 (interpret: add sanity check in dyn upcast to double-check what codegen does) - #127934 (Improve error when a compiler/library build fails in `checktools.sh`) - #127960 (Cleanup dll/exe filename calculations in `run_make_support`) - #127963 (Fix display of logo "border") - #127967 (Disable run-make/split-debuginfo test for RISC-V 64) r? `@ghost` `@rustbot` modify labels: rollup
…ages, r=oli-obk `C-cmse-nonsecure-call`: improved error messages tracking issue: #81391 issue for the error messages (partially implemented by this PR): #81347 related, in that it also deals with CMSE: rust-lang/rust#127766 When using the `C-cmse-nonsecure-call` ABI, both the arguments and return value must be passed via registers. Previously, when violating this constraint, an ugly LLVM error would be shown. Now, the rust compiler itself will print a pretty message and link to more information.
Avoid ref when using format! for perf
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
Rollup of 6 pull requests Successful merges: - #127295 (CFI: Support provided methods on traits) - #127814 (`C-cmse-nonsecure-call`: improved error messages) - #127949 (fix: explain E0120 better cover cases when its raised) - #127966 (Use structured suggestions for unconstrained generic parameters on impl blocks) - #127976 (Lazy type aliases: Diagostics: Detect bivariant ty params that are only used recursively) - #127978 (Avoid ref when using format! for perf) r? `@ghost` `@rustbot` modify labels: rollup
…aumeGomez Update jsondocck directives to follow ui_test-style Context: Comment chain in #125813. Follow-up to #126788. Use the same temporary approach of "double parsing" until we figure out how we want to support compiletest/ui_test directive "add-ons" for child test runners like HtmlDocCk and JsonDocCk. I didn't touch much of jsondocck because I want to refactor it some other time (for robustness, maintainability and better diagnostics; basically by following a similar design of my WIP HtmlDocCk-next, cc #125780). r? `@GuillaumeGomez`
Member
|
@bors r+ |
Contributor
Contributor
Contributor
|
☀️ Test successful - checks-actions |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
No description provided.