-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Rollup of 12 pull requests #144876
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 12 pull requests #144876
Conversation
Let's wait with lldb testing until the test works properly with gdb.
Since it's cfg'd instead of type-aliased
Do not write dummy bindings to extern prelude. Use more precise `Used::Scope` while recording use and remove now redundant `introduced_by_item` check.
Replace commented-out code with link to context for change. Co-authored-by: Ralf Jung <post@ralfj.de>
…t pointer in array on macOS
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.
…ce-impl, r=Mark-Simulacrum Mark `slice::swap_with_slice` unstably const Tracking issue rust-lang#142204
…, r=Mark-Simulacrum `available_parallelism`: Add documentation for why we don't look at `ulimit`
…oli-obk 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
…ulacrum 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#33013 which unfortunately regressed in **nightly-2023-04-24**. See rust-lang#33013 (comment).
… r=Mark-Simulacrum 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.
…oss35 `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#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#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#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 ```
…=Noratrieb 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#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#144443 (comment).
…lacrum Remove unnecessary `rust_` prefixes part of rust-lang#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#144852 r? libs
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 383b9c4 (parent) -> 07b7dc9 (this PR) Test differencesShow 256 test diffsStage 1
Stage 2
(and 76 additional test diffs) Additionally, 80 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 07b7dc90ee4df5815dbb91ef8e98cb93571230f5 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
📌 Perf builds for each rolled up PR:
previous master: 383b9c447b In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Successful merges:
slice::swap_with_slice
unstably const #142205 (Markslice::swap_with_slice
unstably const)available_parallelism
: Add documentation for why we don't look atulimit
#144188 (available_parallelism
: Add documentation for why we don't look atulimit
)AlignmentEnum
should just berepr(usize)
now #144667 (AlignmentEnum
should just berepr(usize)
now)*-lynxos178-*
target maintainer handle to make it easier to copy/paste #144811 (Stylize*-lynxos178-*
target maintainer handle to make it easier to copy/paste)rust_
prefixes #144853 (Remove unnecessaryrust_
prefixes)Failed merges:
#[coroutine]
to the new attribute system #144794 (Port#[coroutine]
to the new attribute system)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup