Automatic Rustup #4513
Merged
Automatic Rustup #4513
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
Optimize region constraints r? `@lcnr`
Update cargo 3 commits in a7fcef21feb4d835d1fee83b3f93b4aef86d5545..840b83a10fb0e039a83f4d70ad032892c287570a 2025-07-13 02:25:52 +0000 to 2025-07-30 13:59:19 +0000 - chore: fix some minor issues in comments (rust-lang/cargo#15787) - feat(schema): Expose `IndexPackage`, the description of a package within a Registry Index (rust-lang/cargo#15770) - chore: update toml/toml_edit to latest (rust-lang/cargo#15779) r? ghost
Remove the witness type from coroutine *args* (without actually removing the type) This does as much of rust-lang/rust#144157 as we can without having to break rust-lang/rust#143545 and/or introduce some better way of handling higher ranked assumptions. Namely, it: * Stalls coroutines based off of the *coroutine* type rather than the witness type. * Reworks the dtorck constraint hack to not rely on the witness type. * Removes the witness type from the args of the coroutine, eagerly creating the type for nested obligations when needed (auto/clone impls). I'll experiment with actually removing the witness type in a follow-up. r? lcnr
Perform check_private_in_public by module. Based on rust-lang/rust#116316
Detect more `cfg`d out items in resolution errors
Use a visitor to collect *all* items (including those nested) that were stripped behind a `cfg` condition.
```
error[E0425]: cannot find function `f` in this scope
--> $DIR/nested-cfg-attrs.rs:4:13
|
LL | fn main() { f() }
| ^ not found in this scope
|
note: found an item that was configured out
--> $DIR/nested-cfg-attrs.rs:2:4
|
LL | fn f() {}
| ^
note: the item is gated here
--> $DIR/nested-cfg-attrs.rs:1:35
|
LL | #[cfg_attr(all(), cfg_attr(all(), cfg(FALSE)))]
| ^^^^^^^^^^
```
Improve bound const handling A few changes to make const handling more similar to type handling. r? `@compiler-errors` -errors
expand WF obligations when checking method calls Don't wrap a bunch of signatures in `FnPtr` then check their WF; instead, check the WFness of each input/output separately. This is useful for the new trait solver, since because we stall on root obligations we end up needing to repeatedly recompute the WFness of possibly very large function signature types if it ends up bottoming out in ambiguity. This may also give us more chances to hit the WF fast path for certain types like built-ins. Finally, this just seems conceptually correct to do. There's nothing conceptually that suggests that wrapping the function signature in an fn pointer makes sense at all to do; I'm guessing that it was just convenient so that we didn't have to register WF obligations in a loop, but it doesn't affect the readability of this code at all.
dont assemble shadowed impl candidates Fixes rust-lang/trait-system-refactor-initiative#109. I've originally intended to fix this by supporting lazy reevaluation when rerunning cycles. This ended up being really difficult, see https://github.com/lcnr/search_graph for my notes used while working on this. It is also insufficient for the `rayon-hang-2.rs` test as we end up with goals which we need to rerun for all combinations of provisional results. While landing such an optimization in the future may still be desirable, it is very difficult and insufficient to fix these hangs. Also see the relevant [zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rustc-rayon.20hang/near/527850058). I was previously opposed to avoiding assembling shadowed impls as it may prevent future improvements in this area, cc rust-lang/rust#141226. Going to track this and the reasoning behind it in rust-lang/trait-system-refactor-initiative#226. r? `@BoxyUwU` `@compiler-errors`
…r=Mark-Simulacrum Mark `slice::swap_with_slice` unstably const Tracking issue rust-lang/rust#142204
…Simulacrum `available_parallelism`: Add documentation for why we don't look at `ulimit`
Add lint against dangling pointers from local variables
## `dangling_pointers_from_locals`
*warn-by-default*
The `dangling_pointers_from_locals` lint detects getting a pointer to data of a local that will be dropped at the end of the function.
### Example
```rust
fn f() -> *const u8 {
let x = 0;
&x // returns a dangling ptr to `x`
}
```
```text
warning: a dangling pointer will be produced because the local variable `x` will be dropped
--> $DIR/dangling-pointers-from-locals.rs:10:5
|
LL | fn simple() -> *const u8 {
| --------- return type of the function is `*const u8`
LL | let x = 0;
| - `x` is defined inside the function and will be drop at the end of the function
LL | &x
| ^^
|
= note: pointers do not have a lifetime; after returning, the `u8` will be deallocated at the end of the function because nothing is referencing it as far as the type system is concerned
= note: `#[warn(dangling_pointers_from_locals)]` on by default
```
### Explanation
Returning a pointer from a local value will not prolong its lifetime, which means that the value can be dropped and the allocation freed while the pointer still exists, making the pointer dangling.
If you need stronger guarantees, consider using references instead, as they are statically verified by the borrow-checker to never dangle.
------
This is related to GitHub codeql [CWE-825](https://github.com/github/codeql/blob/main/rust/ql/src/queries/security/CWE-825/AccessAfterLifetimeBad.rs) which shows examples of such simple miss-use.
It should be noted that C compilers warns against such patterns even without `-Wall`, https://godbolt.org/z/P7z98arrc.
------
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
tests: Add test for basic line-by-line stepping in a debugger Let's wait with lldb testing until the test works properly with gdb. This is a regression test to prevent further regressions of rust-lang/rust#33013 which unfortunately regressed in **nightly-2023-04-24**. See rust-lang/rust#33013 (comment).
…imulacrum Enable extract-insert-dyn.rs test on RISC-V (riscv64) This PR adds support for running the `tests/codegen-llvm/simd/extract-insert-dyn.rs` test on the RISC-V (riscv64) architecture. Previously, this test would fail on RISC-V targets due to architecture-specific code generation issues. This patch modifies the test to ensure compatibility while preserving its intent. The change has been tested locally using `./x test` on a riscv64 target, and the test now passes as expected. ### Notes: - This change is scoped specifically to improve RISC-V compatibility. - It does not affect behavior or test results on other architectures.
`AlignmentEnum` should just be `repr(usize)` now These used to use specific sizes because they were compiled on all widths. But now that the types themselves are `#[cfg]`'d, we can save some conversions by having it always be `repr(usize)`.
Do not give function allocations alignment in consteval and Miri. We do not yet have a (clear and T-lang approved) design for how `#[align(N)]` on functions should affect function pointers' addresses on various platforms, so for now do not give function pointers alignment in consteval and Miri. ---- Old summary: Not a full solution to <rust-lang/rust#144661>, but fixes the immediate issue by making function allocations all have alignment 1 in consteval, ignoring `#[rustc_align(N)]`, so the compiler doesn't know if any offset other than 0 is non-null. A more "principlied" solution would probably be to make function pointers to `#[instruction_set(arm::t32)]` functions be at offset 1 of an align-`max(2, align attribute)` allocation instead of at offset 0 of their allocation during consteval, and on wasm to either disallow `#[align(N)]` where N > 1, or to pad the function table such that the function pointer of a `#[align(N)]` function is a multiple of `N` at runtime.
resolve: Cleanups and micro-optimizations to extern prelude This is what can be done without changing the structure of `ExternPreludeEntry`, like in rust-lang/rust#144737. See individual commits for details.
Regression test for LLVM error with unsupported expression in static initializer for const pointer in array on macOS. Regression test for rust-lang/rust#89225, I have shortened the original example as much as i could, while still generating the error. here is my output on MacOs: ``` rustup run 1.60 cargo build --release Compiling rug_int v0.1.0 (/Users/luca/dev/rug_int) LLVM ERROR: Unsupported expression in static initializer: zext (i64 ptrtoint (<{ [4 x i8] }>* `@anon.fad58de7366495db4650cfefac2fcd61.0` to i64) to i128) error: could not compile `rug_int` rustup run 1.61 cargo build --release Compiling rug_int v0.1.0 (/Users/luca/dev/rug_int) Finished release [optimized] target(s) in 0.60s ```
Stylize `*-lynxos178-*` target maintainer handle to make it easier to copy/paste Apparently I forgot to submit this branch I had lying around. Noticed while reviewing Tier 3 target platform support pages. In the same style as rust-lang/rust#139028.
For "stage 1" ui-fulldeps, use the stage 1 compiler to query target info Testing ui-fulldeps in "stage 1" actually uses the stage 0 compiler, so that test programs can link against stage 1 rustc crates. Unfortunately, using the stage 0 compiler causes problems when compiletest tries to obtain target information from the compiler, but the output format has changed since the last bootstrap beta bump. We can work around this by also providing compiletest with a stage 1 compiler, and having it use that compiler to query for target information. --- This fixes the stage 1 ui-fulldeps failure seen at rust-lang/rust#144443 (comment).
Remove unnecessary `rust_` prefixes part of rust-lang/rust#116005 Honestly, not sure if this can affect linking somehow, also I didn't touched things like `__rust_panic_cleanup` and `__rust_start_panic` which very likely will break something, so just small cleanup here also didn't changed `rust_panic_without_hook` because it was renamed here rust-lang/rust#144852 r? libs
Rollup of 12 pull requests Successful merges: - rust-lang/rust#142205 (Mark `slice::swap_with_slice` unstably const) - rust-lang/rust#144188 (`available_parallelism`: Add documentation for why we don't look at `ulimit`) - rust-lang/rust#144322 (Add lint against dangling pointers from local variables) - rust-lang/rust#144497 (tests: Add test for basic line-by-line stepping in a debugger) - rust-lang/rust#144559 (Enable extract-insert-dyn.rs test on RISC-V (riscv64)) - rust-lang/rust#144667 (`AlignmentEnum` should just be `repr(usize)` now) - rust-lang/rust#144706 (Do not give function allocations alignment in consteval and Miri.) - rust-lang/rust#144746 (resolve: Cleanups and micro-optimizations to extern prelude) - rust-lang/rust#144785 (Regression test for LLVM error with unsupported expression in static initializer for const pointer in array on macOS.) - rust-lang/rust#144811 (Stylize `*-lynxos178-*` target maintainer handle to make it easier to copy/paste) - rust-lang/rust#144848 (For "stage 1" ui-fulldeps, use the stage 1 compiler to query target info) - rust-lang/rust#144853 (Remove unnecessary `rust_` prefixes) Failed merges: - rust-lang/rust#144794 (Port `#[coroutine]` to the new attribute system) r? `@ghost` `@rustbot` modify labels: rollup
This updates the rust-version file to 07b7dc90ee4df5815dbb91ef8e98cb93571230f5.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 07b7dc90ee4df5815dbb91ef8e98cb93571230f5 Filtered ref: 3785af8 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
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.
Update
rustcto rust-lang/rust@07b7dc9.