Automatic Rustup #3913
Merged
Automatic Rustup #3913
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…gjubilee rustc_llvm: adapt to flattened CLI args in LLVM This changed in llvm/llvm-project@e190d07. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19. `@rustbot` label: +llvm-main try-job: x86_64-msvc
…d, r=jieyouxu fix rustc_nonnull_optimization_guaranteed docs As far as I can tell, even back when this was [added](rust-lang/rust#60300) it never *enabled* any optimizations. It just indicates that the FFI compat lint should accept those types for NPO.
Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const. Relevant tracking issue: #130698 The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const." With the stabilisation of [`const_mut_refs`](rust-lang/rust#57349), this simply requires adding the `const` specifier to the function signatures.
Miri subtree update r? `@ghost`
Fix docs of compare_bytes The docs of `compare_bytes`. The return value is positive if <del>`right`</del> `left` is greater
delay uncapping the max_read_size in File::read_to_end In rust-lang/rust#130600 (comment) I realized that we're likely still passing too-large buffers to the OS, at least once at the end. Previous issues and PRs: * #110650 * #110655 * #118222 r? ChrisDenton
Rollup of 5 pull requests Successful merges: - #130658 (Fix docs of compare_bytes) - #130670 (delay uncapping the max_read_size in File::read_to_end) - #130690 (interpret: remove outdated FIXME) - #130692 (make unstable Result::flatten a const fn) - #130702 (Add some missing unstable book tracking issue links) r? `@ghost` `@rustbot` modify labels: rollup
Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang/rust#130678 more clear. It looks like not calling this function was just an oversight in rust-lang/rust#76859, but clearly not a major one because it's taken us 4 years to notice. try-job: i686-msvc
Apply `EarlyOtherwiseBranch` to scalar value In the future, I'm thinking of hoisting discriminant via GVN so that we only need to write very little code here. r? `@cjgillot`
Update to LLVM 19.1.0 This is a branch rebase of the submodule, now that LLVM 19.1.0 is final. Our *only* extra patch right now is the one we're carrying for SGX unwind.
std: implement the `random` feature (alternative version) Implements the ACP rust-lang/libs-team#393. This PR is an alternative version of #129120 that replaces `getentropy` with `CCRandomGenerateBytes` (on macOS) and `arc4random_buf` (other BSDs), since that function is not suited for generating large amounts of data and should only be used to seed other CPRNGs. `CCRandomGenerateBytes`/`arc4random_buf` on the other hand is (on modern platforms) just as secure and uses its own, very strong CPRNG (ChaCha20 on the BSDs, AES on macOS) periodically seeded with `getentropy`.
bootstrap: Set the dylib path when building books with rustdoc
The library path is needed when the toolchain has been configured with
`[rust] rpath = false`. Otherwise, building the reference book will get
an error when it tries to run rustdoc, like:
rustdoc: error while loading shared libraries: librustc_driver-2ec457c3b8826b72.so
…enkov Fix `break_last_token`. It currently doesn't handle the three-char tokens `>>=` and `<<=` correctly. These can be broken twice, resulting in three individual tokens. This is a latent bug that currently doesn't cause any problems, but does cause problems for #124141, because that PR increases the usage of lazy token streams. r? `@petrochenkov`
Remove x86_64-fuchsia and aarch64-fuchsia target aliases Closes #106649.
…ouxu Add more test cases for block-no-opening-brace Also add FIXME's for #80931 & #78168
…rrors Add rustfmt 2024 reformatting to git blame ignore rust-lang/rust#130724 essentially reformatted the world, so we should add it to the git blame ignore list. Tested with `git blame compiler/rustc_abi/src/lib.rs -L1137,1146`. I first thought that I have to ignore the merge commit, but it seems like the actual commit that did the reformatting should be ignored instead. r? ``@compiler-errors``
Rollup of 7 pull requests Successful merges: - #129201 (std: implement the `random` feature (alternative version)) - #130536 (bootstrap: Set the dylib path when building books with rustdoc) - #130551 (Fix `break_last_token`.) - #130657 (Remove x86_64-fuchsia and aarch64-fuchsia target aliases) - #130721 (Add more test cases for block-no-opening-brace) - #130736 (Add rustfmt 2024 reformatting to git blame ignore) - #130746 (readd `@tgross35` and `@joboet` to the review rotation) r? `@ghost` `@rustbot` modify labels: rollup
add unqualified_local_imports lint This lint helps deal with rust-lang/rustfmt#4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
remove workaround for make prepare and use dry-run build instead Removes an annoying hard-coded logic. try-job: x86_64-msvc
Rework `non_local_definitions` lint to only use a syntactic heuristic This PR reworks the `non_local_definitions` lint to only use a syntactic heuristic, i.e. not use a type-system logic for whenever an `impl` is local or not. Instead the new logic wanted by T-lang in rust-lang/rust#126768 (comment), which is to consider every paths in `Self` and `Trait` and to no longer use the type-system inference trick. `@rustbot` labels +L-non_local_definitions Fixes #126768
…Gomez rustdoc: redesign toolbar and disclosure widgets Fixes #77899 Fixes #90310 ## Preview | before | after | ------ | ----- |  |  |  |  |  |  |  |  |  |  | N/A |  |  |  |  |  https://notriddle.com/rustdoc-html-demo-12/toolbar-v2/std/index.html ## Description This adds labels to the icons and moves them away from the search box. These changes are made together, because they work together, but are based on several complaints: * The [+/-] thing are a Reddit-ism. They don't look like buttons, but look like syntax <https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/More.20visual.20difference.20for.20the.20.2B.2F-.20.20Icons>, <rust-lang/rust#59851> (some of these are laundry lists with more suggestions, but they all mention [+/-] looking wrong) * The settings, help, and summary buttons are also too hard to recognize <https://lwn.net/Articles/987070/>, <rust-lang/rust#90310>, <rust-lang/rust#14475 (comment)>, <https://internals.rust-lang.org/t/improve-rustdoc-design/12758> ("Not all functionality is self-explanatory, for example the [+] button in the top right corner, the theme picker or the settings button.") The toggle-all and toggle-individual buttons both need done at once, since we want them to look like they go together. This changes them from both being [+/-] to both being arrows. CC <rust-lang/rust#113074 (comment)> and ``@jsha`` regarding the use of triangles for disclosure, which is what everyone wanted, but was pending a good toggle-all button. This PR adds a toggle-all button that should work. Settings and Help are also migrated, so that the whole group can benefit from being described using actual words. The breadcrumbs also get redesigned, so that they use less space, by shrinking the parent module path parts. This is done at the same time as the toolbar redesign because it's, effectively, moving space from the toolbar to the breadcrumbs. This is aimed at avoiding any line wrapping at desktop sizes. ## Prior art This style of toolbar, with explicit labels on the buttons, used to be more popular. It's not very common in web browsers nowadays, and for truly universal icons like ⬅️ I can understand why, but words are great when icons fail. 
Skip query in get_parent_item when possible. For HirIds with a non-zero item local id, `self.parent_owner_iter(hir_id).next()` just returns the same HirId with the item local id set to 0, but also does a query to retrieve the Node which is ignored here, which seems wasteful.
Check vtable projections for validity in miri Currently, miri does not catch when we transmute `dyn Trait<Assoc = A>` to `dyn Trait<Assoc = B>`. This PR implements such a check, and fixes #3905. To do this, we modify `GlobalAlloc::VTable` to contain the *whole* list of `PolyExistentialPredicate`, and then modify `check_vtable_for_type` to validate the `PolyExistentialProjection`s of the vtable, along with the principal trait that was already being validated. cc ``@RalfJung`` r? ``@lcnr`` or types I also tweaked the diagnostics a bit. --- **Open question:** We don't validate the auto traits. You can transmute `dyn Foo` into `dyn Foo + Send`. Should we check that? We currently have a test that *exercises* this as not being UB: https://github.com/rust-lang/rust/blob/6c6d210089e4589afee37271862b9f88ba1d7755/src/tools/miri/tests/pass/dyn-upcast.rs#L14-L20 I'm not actually sure if we ever decided that's actually UB or not 🤔 We could perhaps still check that the underlying type of the object (i.e. the concrete type that was unsized) implements the auto traits, to catch UB like: ```rust fn main() { let x: &dyn Trait = &std::ptr::null_mut::<()>(); let _: &(dyn Trait + Send) = std::mem::transmute(x); //~^ this vtable is not allocated for a type that is `Send`! } ```
Add new Tier-3 target: `loongarch64-unknown-linux-ohos` MCP: rust-lang/compiler-team#784
…eyouxu Revert "Add recursion limit to FFI safety lint" It's not necessarily clear if warning when we hit the recursion limit is the right thing to do, first of all. **More importantly**, this PR was implemented incorrectly in the first place; it was not decrementing the recursion limit when stepping out of a type, so it would trigger when a ctype has more than RECURSION_LIMIT fields *anywhere* in the type's set of recursively reachable fields. Reverts #130598 Reopens #130310 Fixes #130757
add InProgress ErrorKind gated behind io_error_inprogress feature Follow up on rust-lang/libs-team#92 (comment)
…skrgr Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure Fixes rust-lang/rust#130776. r? `@matthiaskrgr` (or compiler/bootstrap)
rustdoc: inherit parent's stability where applicable It is currently not possible for a re-export to have a different stability (rust-lang/rust#30827). Therefore the standard library uses a hack when moving items like `std::error::Error` or `std::net::IpAddr` into `core` by marking the containing module (`core::error` / `core::net`) as unstable or stable in a later version than the items the module contains. Previously, rustdoc would always show the *stability as declared* for an item rather than the *stability as publicly reachable* (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing. fixes rust-lang/rust#130765 screenshots:  
Rollup of 7 pull requests Successful merges: - #130234 (improve compile errors for invalid ptr-to-ptr casts with trait objects) - #130752 (Improve assembly test for CMSE ABIs) - #130764 (Separate collection of crate-local inherent impls from error tracking) - #130788 (Pin memchr to 2.5.0 in the library rather than rustc_ast) - #130789 (add InProgress ErrorKind gated behind io_error_inprogress feature) - #130793 (Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure) - #130798 (rustdoc: inherit parent's stability where applicable) Failed merges: - #130735 (Simple validation for unsize coercion in MIR validation) r? `@ghost` `@rustbot` modify labels: rollup
|
@bors r+ |
RalfJung
force-pushed
the
rustup-2024-09-25
branch
from
20f4c4f to
d939a09
Compare
…of 'align' for heap allocator coverage, move 'hello' to UNIX HashMap now needs pretty target-specific randomness functions. It still works on Android, but not on FreeBSD and Solarish.
RalfJung
force-pushed
the
rustup-2024-09-25
branch
from
d939a09 to
e649d14
Compare
|
💔 Test failed - checks-actions |
|
Had to also disable the AVR test due to rust-lang/rust#130818. @bors r+ |
|
☀️ Test successful - checks-actions |
This was referenced Sep 25, 2024
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.
No description provided.