Automatic Rustup #4615
Merged
Automatic Rustup #4615
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-miri[bot]](https://avatars.githubusercontent.com/u/5430905?s=80&v=4){kind=small}
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: caccb4d0368bd918ef6668af8e13834d07040417 Filtered ref: 0f345ed05d559bbfb754f1403b16199366cda2e0 Upstream diff: rust-lang/rust@21a19c2...caccb4d This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
fix SCIP panicking due to salsa not attaching
Remove non-ns version of impl_self_ty and impl_trait
Fix fixes for unused raw variables
Fix applicable on if-let-chain for invert_if
…-ret Add let-chain support for convert_to_guarded_return
Add const parameter keyword completion
Add cfg_attr predicate completion
Fix precedence parenthesis for replace_arith_op
Add applicable on bang `!` for apply_demorgan
Allow `&raw [mut | const]` for union field
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: f957826bff7a68b267ce75b1ea56352aed0cca0a Filtered ref: 7291893f9d875b6e8775a7a0e661abdaec15d3c1 Upstream diff: rust-lang/rust@caccb4d...f957826 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Add `all` `any` and `not` attribute completions
…cro-by-example Fix negative integer literals in const generics in declarative macro context
Make replacement suggestion `_` in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@a6bc4a4. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Turn ProjectionElem::Subtype into CastKind::Subtype I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.) The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant. cc rust-lang/rust#112651, rust-lang/rust#133258 r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
Split Bound index into Canonical and Bound See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run. r? lcnr
…r=Mark-Simulacrum Support `#[rustc_align_static]` inside `thread_local!` Tracking issue: rust-lang/rust#146177 ```rust thread_local! { #[rustc_align_static(64)] static SO_ALIGNED: u64 = const { 0 }; } ``` This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case. r? libs ``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
mbe: Implement `unsafe` attribute rules This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](rust-lang/rfcs#3697). An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax. An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax. `unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule. Tracking issue for `macro_rules!` attributes: rust-lang/rust#143547
indexing: reword help After looking at rust-lang/rust#40850, I thought I'd try to improve wording around error E0608 a bit. Hopefully I've succeeded.
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
Forbid `//@ compile-flags: -Cincremental=` in tests Tests should not try to manually enable incremental compilation with `-Cincremental`, because that typically results in stray directories being created in the repository root. Also, if the incremental directory is not cleared, there is a risk of interference between successive runs of the same test. Instead, use the `//@ incremental` directive, which instructs compiletest to handle the details of passing `-Cincremental` with a fresh directory.
…ichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang/rust#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang/rust#77839. r? ``@alexcrichton``
implement `Box::take` Tracking issue: rust-lang/rust#147212 I'm not entirely sure about the wording of the doc comment, if anyone has any suggestions that'd be great :)
Initialize llvm submodule if not already the case to run citool While working on rust-lang/rust#146414, I ran the following command (to run CI docker locally): ``` cargo run --manifest-path src/ci/citool/Cargo.toml run-local --type pr x86_64-gnu-gcc ``` However, since I didn't have `src/llvm` submodule initialized, it failed. Apparently it's a common issue for people using this tool so this PR removes this small inconvenience. r? ``@Kobzol``
Update books ## rust-lang/book 1 commits in 33f1af40cc44dde7e3e892f7a508e6f427d2cbc6..1d7c3e6abec2d5a9bfac798b29b7855b95025426 2025-09-28 21:24:16 UTC to 2025-09-28 21:24:16 UTC - Chunk of chapters from copyedit (rust-lang/book#4506) ## rust-lang/edition-guide 1 commits in aa6ce337c0adf7a63e33960d184270f2a45ab9ef..e2ed891f00361efc26616d82590b1c85d7a8920e 2025-10-01 17:11:54 UTC to 2025-10-01 17:11:54 UTC - link to never type fallback lint as deny by default (rust-lang/edition-guide#377) ## rust-lang/nomicon 1 commits in f17a018b9989430967d1c58e9a12c51169abc744..23fc2682f8fcb887f77d0eaabba708809f834c11 2025-09-24 10:10:31 UTC to 2025-09-24 10:10:31 UTC - a typo in ffi.md (rust-lang/nomicon#502) ## rust-lang/reference 13 commits in cc7247d8dfaef4c39000bb12c55c32ba5b5ba976..e11adf6016a362766eea5a3f9832e193994dd0c8 2025-09-29 00:55:42 UTC to 2025-09-23 23:33:32 UTC - const functions: separate rule about users and rule about what is allowed in such functions (rust-lang/reference#2013) - use "tuple enum variant" more consistently (rust-lang/reference#2015) - Remove caveats related to `format_args!` expansion (rust-lang/reference#2017) - RISC-V: Extension Updates (including document references) (rust-lang/reference#2002) - Move inferred sentence to an example block (rust-lang/reference#2019) - Add triagebot range-diff feature (rust-lang/reference#2011) - use AND when searching for multiple terms (rust-lang/reference#2016) - enumerations.md: fix pluralisation (rust-lang/reference#2014) - const_eval.md: use sentence case for section title, for consistency (rust-lang/reference#2012) - destructors.md: improve readability by adding pauses (rust-lang/reference#2007) - RISC-V: Add vector state registers (rust-lang/reference#2005) - destructors.md: point to core:: instead of std:: (rust-lang/reference#2006) - Create Whitespace grammar productions (rust-lang/reference#1991)
Rollup of 9 pull requests Successful merges: - rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang/rust#146585 (indexing: reword help) - rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang/rust#147227 (implement `Box::take`) - rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang/rust#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
…etrochenkov Test: Ambigious bindings in same namespace with the same res Add a test based on the discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542316157) and related to rust-lang/rust#145575 (comment). This is the most reduced form I could create that passes on nightly but fails with rust-lang/rust#145108 (see [#gsoc > Project: Parallel Macro Expansion @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542335131)). Also not sure about the test names. r? `@petrochenkov`
…ine, r=saethlin Extending `#[rustc_force_inline]` to be applicable to inherent methods `#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved). `#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions). Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined. r? `@saethlin`
This updates the rust-version file to 3b8665c5ab3aeced9b01672404c3764583e722ca.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 3b8665c5ab3aeced9b01672404c3764583e722ca Filtered ref: 67ff7e0 Upstream diff: rust-lang/rust@42b384e...3b8665c This merge was created using https://github.com/rust-lang/josh-sync.
|
Thank you for contributing to Miri! |
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.
Merge ref '3b8665c5ab3a' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 3b8665c5ab3aeced9b01672404c3764583e722ca
Filtered ref: 67ff7e0
Upstream diff: rust-lang/rust@42b384e...3b8665c
This merge was created using https://github.com/rust-lang/josh-sync.