Rebase onto current rust-lang/rust master #1
Conversation
This file contains 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
Since we now handle library crates properly, there's no need to panic for `no_std` targets anymore. `x doc library` now generates documentation for the `alloc` crate from standard library. Signed-off-by: onur-ozkan <[email protected]>
`crates` field is handled in the `Step::make_run` just like in any other `Std` implementation, so we don't need to resolve them in `Std::new`. Signed-off-by: onur-ozkan <[email protected]>
Signed-off-by: onur-ozkan <[email protected]>
…rk-Simulacrum handle no_std targets on std builds This PR unifies the `Step::run_make` logic and improves it by skipping std specific crates for no_std targets. In addition, since we now handle library crates properly, bootstrap is capable of running `x doc library` even for no_std targets as it is able to generate documentation for `alloc` crate from the standard library. Resolves rust-lang#128027 cc ``@ChrisDenton``
…li-obk miri: fix offset_from behavior on wildcard pointers offset_from wouldn't behave correctly when the "end" pointer was a wildcard pointer (result of an int2ptr cast) just at the end of the allocation. Fix that by expressing the "same allocation" check in terms of two `check_ptr_access_signed` instead of something specific to offset_from, which is both more canonical and works better with wildcard pointers. The second commit just improves diagnostics: I wanted the "pointer is dangling (has no provenance)" message to say how many bytes of memory it expected to see (since if it were 0 bytes, this would actually be legal, so it's good to tell the user that it's not 0 bytes). And then I was annoying that the error looks so different for when you deref a dangling pointer vs an out-of-bounds pointer so I made them more similar. Fixes rust-lang/miri#3767
…eril Isolate the diagnostic code that expects `thir::Pat` to be printable Currently, `thir::Pat` implements `fmt::Display` (and `IntoDiagArg`) directly, for use by a few diagnostics. That makes it tricky to experiment with alternate representations for THIR patterns, because the patterns currently need to be printable on their own. That immediately rules out possibilities like storing subpatterns as a `PatId` index into a central list (instead of the current directly-owned `Box<Pat>`). This PR therefore takes an incremental step away from that obstacle, by removing `thir::Pat` from diagnostic structs in `rustc_pattern_analysis`, and hiding the pattern-printing process behind a single public `Pat::to_string` method. Doing so makes it easier to identify and update the code that wants to print patterns, and gives a place to pass in additional context in the future if necessary. --- I'm currently not sure whether switching over to `PatId` is actually desirable or not, but I think this change makes sense on its own merits, by reducing the coupling between `thir::Pat` and the pattern-analysis error types.
…aumeGomez Clean and enable `rustdoc::unescaped_backticks` for `core/alloc/std/test/proc_macro` I am not sure if the lint is supposed to be "ready enough" (since it is `allow` by default), but it does catch a couple issues in `core` (`alloc`, `std`, `test` and `proc_macro` are already clean), so I propose making it `warn` in all the crates rendered in the website. Cc: `@GuillaumeGomez`
CI: move RFL job forward to v6.11-rc1 The tag has been released today, and since the original hash we had in the Rust CI (which was ~v6.10-rc1), we have accumulated a fair amount of changes and new code. In particular, v6.11-rc1 is the first Linux tag where the kernel is supporting an actual minimum Rust version (1.78.0), rather than a single version. --- Let's try to do the move independently first. r? ``@Kobzol`` try-job: x86_64-rust-for-linux
Miri subtree update r? `@ghost`
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#128182 (handle no_std targets on std builds) - rust-lang#128277 (miri: fix offset_from behavior on wildcard pointers) - rust-lang#128304 (Isolate the diagnostic code that expects `thir::Pat` to be printable) - rust-lang#128307 (Clean and enable `rustdoc::unescaped_backticks` for `core/alloc/std/test/proc_macro`) - rust-lang#128322 (CI: move RFL job forward to v6.11-rc1) - rust-lang#128333 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
feat: use vscode log format for client logs This change updates the log format to use the vscode log format instead of the custom log format, by replacing the `OutputChannel` with a `LogOutputChannel` and using the `debug`, `info`, `warn`, and `error` methods on it. This has the following benefits: - Each log level now has its own color and the timestamp is in a more standard format - Inspect output (e.g. the log of the config object) is now colored - Error stack traces are now shown in the output - The log level is now controlled on the output tab by clicking the gear icon and selecting "Debug" or by passing the `--log` parameter to vscode. The `trace.extension` setting has been marked as deprecated. Motivation: The large uncolored unformatted log output with a large config object logged whenever it changes has always dominated the logs. This subjectively has made it that looking to see what the client is doing has always been a bit disappointing. That said, there's only 17 log messages total in the client. Hopefully by making the logs more visually useful this will encourage adding more appropriate debug level messages in future. Incidentally, it might be worth only logging the config change message at a debug level instead of an info level to reduce the noise.
… r=Veykril fix: let glob imports override other globs' visibility Follow up to rust-lang#14930 Fixes rust-lang#11858 Fixes rust-lang#14902 Fixes rust-lang#17704 I haven't reworked the code here at all - I don't feel confident in the codebase to do so - just rebased it onto the current main branch and fixed conflicts. I'm not _entirely_ sure I understand the structure of the `check` function in `crates/hir-def/src/nameres` tests. I think the change to the test expectation from rust-lang#14930 is correct, marking the `crate::reexport::inner` imports with `i`, and I understand it to mean there's a specific token in the import that we can match it to (in this case, `Trait`, `function` and `makro` of `pub use crate::defs::{Trait, function, makro};` respectively), but I had some trouble understanding the meaning of the different parts of `PerNs` to be sure. Does this make sense? I tested building and using RA locally with `cargo xtask install` and after this change the documentation for `arrow_array::ArrowPrimitiveType` seems to be picked up correctly!
This reverts commit 752c49b679afcec7edf5d26d52bf3d164ee7349f.
…=saethlin Perform instsimplify before inline to eliminate some trivial calls I am currently working on rust-lang#128081. In the current pipeline, we can get the following clone statements ([godbolt](https://rust.godbolt.org/z/931316fhP)): ``` bb0: { StorageLive(_2); _2 = ((*_1).0: i32); StorageLive(_3); _3 = ((*_1).1: u64); _0 = Foo { a: move _2, b: move _3 }; StorageDead(_3); StorageDead(_2); return; } ``` Analyzing such statements will be simple and fast. We don't need to consider branches or some interfering statements. However, this requires us to run `InstSimplify`, `ReferencePropagation`, and `SimplifyCFG` at least once. I can introduce a new pass, but I think the best place for it would be within `InstSimplify`. I put `InstSimplify` before `Inline`, which takes some of the burden away from `Inline`. r? `@saethlin`
feat(ide-completion): explictly show `async` keyword on `impl trait` methods OLD: <img width="676" alt="image" src="https://github.com/user-attachments/assets/f6fa626f-6b6d-4c22-af27-b0755e7a6bf8"> Now: <img width="684" alt="image" src="https://github.com/user-attachments/assets/efbaac0e-c805-4dd2-859d-3e44b2886dbb"> --- This is an preparation for rust-lang/rust-analyzer#17719. ```rust use std::future::Future; trait DesugaredAsyncTrait { fn foo(&self) -> impl Future<Output = usize> + Send; fn bar(&self) -> impl Future<Output = usize> + Send; } struct Foo; impl DesugaredAsyncTrait for Foo { fn foo(&self) -> impl Future<Output = usize> + Send { async { 1 } } // async fn bar(&self) -> usize { 1 } } fn main() { let fut = Foo.bar(); fn _assert_send<T: Send>(_: T) {} _assert_send(fut); } ``` If we don't distinguish `async` or not. It would be confusing to generate sugared version `async fn foo ....` and original form `fn foo` for `async fn in trait` that is defined in desugar form.
Signed-off-by: onur-ozkan <[email protected]>
…unknown-linux-target-page, r=pietroalbini Add target page for riscv64gc-unknown-linux-gnu I was reading rust-lang#113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
…fe_fn, r=joboet fix(hermit): `deny(unsafe_op_in_unsafe_fn)` Tracking issue: rust-lang#127747 r? workingjubilee CC: ``@stlankes``
interpret: on a signed deref check, mention the right pointer in the error When a negative offset (like `ptr.offset(-10)`) goes out-of-bounds, we currently show an error saying that we expect the *resulting* pointer to be inbounds for 10 bytes. That's confusing, so this PR makes it so that instead we say that we expect the *original* pointer `ptr` to have 10 bytes *to the left*. I also realized I can simplify the pointer arithmetic logic and handling of "staying inbounds of a target `usize`" quite a bit; the second commit does that.
…compiler-errors Fix removed `box_syntax` diagnostic if source isn't available Fix rust-lang#128442
fix dropck documentation for `[T;0]` special-case fixes rust-lang#110288. r? ``@lcnr``
…ing, r=tgross35 chore: refactor backtrace formatting Replace `write_str()` with the `writeln!()` macro, consolidating multiple write operations.
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#127490 (Add target page for riscv64gc-unknown-linux-gnu) - rust-lang#128433 (fix(hermit): `deny(unsafe_op_in_unsafe_fn)`) - rust-lang#128482 (interpret: on a signed deref check, mention the right pointer in the error) - rust-lang#128496 (Fix removed `box_syntax` diagnostic if source isn't available) - rust-lang#128497 (fix dropck documentation for `[T;0]` special-case) - rust-lang#128499 (chore: refactor backtrace formatting) r? `@ghost` `@rustbot` modify labels: rollup
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all. Fix clippy lint suggestion incorrectly treated as `span_help`.
rustdoc: Remove OpaqueTy r? `@ghost` Apparently this works lol?!? try-job: aarch64-apple
Migrate and rename `issue-47551`, `issue-35164` and `issue-69368` `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). try-job: dist-x86_64-msvc
…r=jieyouxu migrate fmt-write-bloat to rmake try-job: aarch64-apple try-job: x86_64-gnu-llvm-18 try-job: dist-x86_64-linux
…wiser Better handle suggestions for the already present code and fix some suggestions When a suggestion part is for code that is already present, skip it. If all the suggestion parts for a suggestion are for code that is already there, do not emit the suggestion. Fix two suggestions that treat `span_suggestion` as if it were `span_help`.
…lubby789 Update sysinfo version to 0.31.2 I needed to update `memchr` version (which was pinned in rust-lang@36a1679). So let's see if it triggers the linker issue. try-job: x86_64-mingw
raw_eq: using it on bytes with provenance is not UB (outside const-eval) The current behavior of raw_eq violates provenance monotonicity. See rust-lang#124921 for an explanation of provenance monotonicity. It is violated in raw_eq because comparing bytes without provenance is well-defined, but adding provenance makes the operation UB. So remove the no-provenance requirement from raw_eq. However, the requirement stays in-place for compile-time invocations of raw_eq, that indeed cannot deal with provenance. Cc `@rust-lang/opsem`
…gjubilee [`macro_metavar_expr_concat`] Dogfooding cc rust-lang#124225 Starts inner usage to test the robustness of the implementation.
…r-errors MIR required_consts, mentioned_items: ensure we do not forget to fill these lists Bodies initially get created with empty required_consts and mentioned_items, but at some point those should be filled. Make sure we notice when that is forgotten.
…melid rustdoc: Remove dead opaque_tys rendering logic rust-lang#127276 removed OpaqueTy from clean, and the code populating AllTypes::opaque_tys, but not this field itself.
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#126818 (Better handle suggestions for the already present code and fix some suggestions) - rust-lang#128436 (Update sysinfo version to 0.31.2) - rust-lang#128453 (raw_eq: using it on bytes with provenance is not UB (outside const-eval)) - rust-lang#128491 ([`macro_metavar_expr_concat`] Dogfooding) - rust-lang#128494 (MIR required_consts, mentioned_items: ensure we do not forget to fill these lists) - rust-lang#128521 (rustdoc: Remove dead opaque_tys rendering logic) r? `@ghost` `@rustbot` modify labels: rollup
Rewrite binary search implementation This PR builds on top of rust-lang#128250, which should be merged first. This restores the original binary search implementation from rust-lang#45333 which has the nice property of having a loop count that only depends on the size of the slice. This, along with explicit conditional moves from rust-lang#128250, means that the entire binary search loop can be perfectly predicted by the branch predictor. Additionally, LLVM is able to unroll the loop when the slice length is known at compile-time. This results in a very compact code sequence of 3-4 instructions per binary search step and zero branches. Fixes rust-lang#53823 Fixes rust-lang#115271
does not compile after rebase (by @futile) Co-authored-by: Felix Rath <[email protected]>
does not compile after rebase (by @futile) Co-authored-by: Felix Rath <[email protected]>
Co-authored-by: Felix Rath <[email protected]>
|
Update: I went ahead and tried to figure out what caused/how to solve the test failures, which resulted in a furthering of the PR. I thus opened up a new PR in rust-lang/rust which is based on this rebase: rust-lang#128605 I hope that is ok, and thanks again for the great changes you made, which make up most of the work! I mainly finished up by adding macro retrying, which was mostly difficult because I'm new to rustc :) Thanks again! |
|
Closing this, discussion is in upstream issues :) |
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.
Hi, I went ahead and did a rebase against rust's current master.
x test tidyandx checkboth pass.Since the first two commits are no longer compatible with master (some new types that don't have
Hash), but the last commit removesHashagain anyway, I marked those two commits as "does not compile". But the final state (with all three commits) compiles again (and passestidy&check).There are two new failures when running
x test tests/ui, but also more tests in total, so that makes sense.Failures from the PR CI: https://github.com/rust-lang/rust/actions/runs/9232104911/job/25402877228?pr=125356
Failures with this rebase:
Is this helpful? Can you see something obvious I missed? Thanks! :)