about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2025-02-11Correctly handle pattern types in FFI safetyOli Scherer-47/+12
2025-02-11Add ffi tests for pattern typesOli Scherer-22/+185
2025-02-11Auto merge of #136845 - matthiaskrgr:rollup-ol4np4z, r=matthiaskrgrbors-498/+934
Rollup of 7 pull requests Successful merges: - #136107 (Introduce CoercePointeeWellformed for coherence checks at typeck stage) - #136155 (Enable sanitizers on MSVC CI jobs) - #136524 (Delay bug when method confirmation cannot upcast object pick of self) - #136584 (Prevent generic pattern types from being used in libstd) - #136603 (compiler: gate `extern "{abi}"` in ast_lowering) - #136821 (assign marcoieni and jdno to infra-ci PRs) - #136825 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-11Auto merge of #127541 - estebank:diff-suggestions, r=petrochenkovbors-6943/+10364
Show diff suggestion format on verbose replacement ``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL - let _ = 2.l; LL + let _ = 2.0f64; | ``` before: ``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL + let _ = 2.0f64; | ~~~~ ``` r? `@oli-obk`
2025-02-11Rollup merge of #136825 - rustbot:docs-update, r=ehussMatthias Krüger-0/+0
Update books ## rust-lang/edition-guide 1 commits in f56aecc3b036dff16404b525a83b00f911b9bbea..8dbdda7cae4fa030f09f8f5b63994d4d1dde74b9 2025-02-06 20:06:58 UTC to 2025-02-06 20:06:58 UTC - Correct spelling error in `static-mut-references.md` (rust-lang/edition-guide#358) ## rust-embedded/book 1 commits in ddbf1b4e2858fedb71b7c42eb15c4576517dc125..0b8219ac23a3e09464e4e0166c768cf1c4bba0d5 2025-02-07 08:26:59 UTC to 2025-02-07 08:26:59 UTC - Update gcc toolchain download link for windows (rust-embedded/book#384) ## rust-lang/reference 3 commits in 4249fb411dd27f945e2881eb0378044b94cee06f..de2d5289e45506b11dd652bef4f99de64be70e1c 2025-02-08 22:12:20 UTC to 2025-02-06 19:02:01 UTC - Add trait_upcasting related languages changes (rust-lang/reference#1622) - fixup `»` insertion for rules (rust-lang/reference#1730) - doc `cenum_impl_drop_cast` (rust-lang/reference#1713) ## rust-lang/rust-by-example 2 commits in 743766929f1e53e72fab74394ae259bbfb4a7619..66543bbc5b7dbd4e679092c07ae06ba6c73fd912 2025-02-06 12:38:08 UTC to 2025-02-04 01:46:09 UTC - Add more examples @ drop.md (rust-lang/rust-by-example#1912) - es translation to 3100 (rust-lang/rust-by-example#1911)
2025-02-11Rollup merge of #136821 - marcoieni:infra-ci-review, r=jackh726Matthias Krüger-0/+2
assign marcoieni and jdno to infra-ci PRs
2025-02-11Rollup merge of #136603 - workingjubilee:move-abi-versioning-into-ast, ↵Matthias Krüger-420/+395
r=compiler-errors compiler: gate `extern "{abi}"` in ast_lowering I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together. It also abstracts away certain error messages instead of constantly repeating them. A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used. r? ``@ghost``
2025-02-11Rollup merge of #136584 - oli-obk:pattern-types-generic, r=BoxyUwUMatthias Krüger-11/+101
Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc #136574 (new tracking issue for the `generic_pattern_types` feature gate) r? ``@lcnr`` cc ``@scottmcm`` ``@joshtriplett``
2025-02-11Rollup merge of #136524 - compiler-errors:bad-pick, r=BoxyUwUMatthias Krüger-9/+47
Delay bug when method confirmation cannot upcast object pick of self Justification is on the test comment. Simply delays a bug that we were previously ICEing on. cc ``@adetaylor`` since this is a `arbitrary_self_types` ICE.
2025-02-11Rollup merge of #136155 - tmiasko:msvc-enable-sanitizers, r=Mark-SimulacrumMatthias Krüger-4/+4
Enable sanitizers on MSVC CI jobs Previously MSVC CI would ignore all tests annotated with needs-sanitizer-support header.
2025-02-11Rollup merge of #136107 - dingxiangfei2009:coerce-pointee-wellformed, ↵Matthias Krüger-54/+385
r=compiler-errors Introduce CoercePointeeWellformed for coherence checks at typeck stage Fix #135206 This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`. This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`. A following series of patch will arrive later to address the following concern. 1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules. 1. Enforcement of data field requirements. **An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`. ``@rustbot`` label F-derive_coerce_pointee
2025-02-10Auto merge of #133092 - madsmtm:bootstrap-deployment-target, ↵bors-26/+134
r=Mark-Simulacrum,jieyouxu Always set the deployment target when building std `cc` has [a bug/feature](https://github.com/rust-lang/cc-rs/issues/1171) (I guess depending on how you look at it) where the default deployment target is taken from the SDK instead of from `rustc`. This causes `compiler-builtins` to build `compiler-rt` with the wrong deployment target on iOS. I've been meaning to change how `cc` works in this regard, but that's a lengthy process, so let's fix it in bootstrap for now. The behaviour can be seen locally with `./x build library --set build.optimized-compiler-builtins=true` for various target triples, and then inspecting with `otool -l build/host/stage1/lib/rustlib/*/lib/libcompiler_builtins-*.rlib | rg 'minos|version'`. I have added a rmake test that ensures that we now have the same version everywhere. Fixes https://github.com/rust-lang/rust/issues/128419 Fixes https://github.com/rust-lang/compiler-builtins/issues/650 Fixes https://github.com/rust-lang/rust/issues/136523 See also https://github.com/rust-lang/cargo/issues/13115, https://github.com/rust-lang/cc-rs/issues/1171, https://github.com/rust-lang/rust/issues/136113 See https://github.com/rust-lang/rust/pull/133092#issuecomment-2626206772 for a description of how the change works. try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: x86_64-apple-1 try-job: aarch64-apple try-job: dist-apple-various try-job: dist-aarch64-apple try-job: dist-various-2 try-job: x86_64-fuchsia
2025-02-10Show diff suggestion format on verbose replacementEsteban Küber-6943/+10364
``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL - let _ = 2.l; LL + let _ = 2.0f64; | ```
2025-02-10Auto merge of #136823 - matthiaskrgr:rollup-vp20mk1, r=matthiaskrgrbors-114/+290
Rollup of 6 pull requests Successful merges: - #136419 (adding autodiff tests) - #136628 (ci: upgrade to crosstool-ng 1.27.0) - #136681 (resolve `llvm-config` path properly on cross builds) - #136714 (Update `compiler-builtins` to 0.1.146) - #136731 (rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync") - #136791 (Disable DWARF in linker options for i686-unknown-uefi) Failed merges: - #136767 (improve host/cross target checking) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-10Update booksrustbot-0/+0
2025-02-10Reword doc comment on `CoercePointeeValidated`Michael Goulet-6/+5
2025-02-10Rollup merge of #136791 - nicholasbishop:bishop-disable-dwarf, r=jieyouxuMatthias Krüger-1/+8
Disable DWARF in linker options for i686-unknown-uefi This fixes an lld warning: > warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table See https://reviews.llvm.org/D69594 for details of where the warning was added. This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of `x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why. The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld. Tested with: ``` export RUSTC_LOG=rustc_codegen_ssa::back::link=info cargo +stage1 build --release --target i686-unknown-uefi ``` This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such. CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
2025-02-10Rollup merge of #136731 - safinaskar:parallel-2025-02-08-07-22, r=SparrowLiiMatthias Krüger-3/+0
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync" rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync" We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349 r? SparrowLii ``@rustbot`` label: +WG-compiler-parallel (rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
2025-02-10Rollup merge of #136714 - tgross35:update-builtins, r=tgross35Matthias Krüger-6/+6
Update `compiler-builtins` to 0.1.146 Exposes the error function so we can expose this in the standard library [1]. [1]: https://github.com/rust-lang/compiler-builtins/pull/753
2025-02-10Rollup merge of #136681 - onur-ozkan:132926, r=jieyouxuMatthias Krüger-3/+132
resolve `llvm-config` path properly on cross builds Fixes #132926 try-job: x86_64-mingw-2
2025-02-10Rollup merge of #136628 - heiher:crosstool-ng-1.27, r=Mark-SimulacrumMatthias Krüger-24/+7
ci: upgrade to crosstool-ng 1.27.0 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl try-job: dist-powerpc64le-linux
2025-02-10Rollup merge of #136419 - EnzymeAD:autodiff-tests, r=onur-ozkan,jieyouxuMatthias Krüger-77/+137
adding autodiff tests I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion? Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as `%0 = fadd fast double %x.0.val, %x.0.val` (I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag) r? ``@jieyouxu`` Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails. Tracking: - https://github.com/rust-lang/rust/issues/124509 Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
2025-02-10assign marcoieni and jdno to infra-ci PRsMarcoIeni-0/+2
2025-02-10Auto merge of #135701 - calebzulawski:sync-from-portable-simd-2025-01-18, ↵bors-424/+880
r=workingjubilee Portable SIMD subtree update r? `@workingjubilee`
2025-02-10add coverage for llvm-config path resolutiononur-ozkan-3/+127
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2025-02-10Auto merge of #136809 - workingjubilee:rollup-jk0pew1, r=workingjubileebors-908/+596
Rollup of 12 pull requests Successful merges: - #136053 (coverage: Defer part of counter-creation until codegen) - #136201 (Removed dependency on the field-offset crate, alternate approach) - #136228 (Simplify Rc::as_ptr docs + typo fix) - #136353 (fix(libtest): Enable Instant on Emscripten targets) - #136472 ([`compiletest`-related cleanups 2/7] Feed stage number to compiletest directly) - #136487 (ci: stop mysql before removing it) - #136552 (Use an `Option` for `FindNextFileHandle` in `ReadDir` instead of `INVALID_FILE_HANDLE` sentinel value) - #136705 (Some miscellaneous edition-related library tweaks) - #136707 (Bump `cc` to v1.2.13 for the compiler workspace) - #136790 (Git blame ignore recent formatting commit) - #136792 (Don't apply editorconfig to llvm) - #136805 (ignore win_delete_self test in Miri) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-10bootstrap: Don't overwrite CFLAGS_* set in the environmentMads Marquart-6/+19
2025-02-10Rollup merge of #136805 - RalfJung:miri-win-delete-self, r=NoratriebJubilee-0/+1
ignore win_delete_self test in Miri Follow-up to https://github.com/rust-lang/rust/pull/134679, fixes miri-test-libstd on Windows Cc `@ChrisDenton` `@Mark-Simulacrum`
2025-02-10Rollup merge of #136792 - jyn514:editor-config, r=jieyouxuJubilee-0/+2
Don't apply editorconfig to llvm They use 2 spaces by default, not 4.
2025-02-10Rollup merge of #136790 - ehuss:ignore-rustfmt-2024-again, r=compiler-errorsJubilee-0/+2
Git blame ignore recent formatting commit This ignores the commit 1fcae03369abb4c2cc180cd5a49e1f4440a81300 from https://github.com/rust-lang/rust/pull/136751 that applied updating formatting changes.
2025-02-10Rollup merge of #136707 - clubby789:cmake-bisect, r=jieyouxuJubilee-4/+4
Bump `cc` to v1.2.13 for the compiler workspace
2025-02-10Rollup merge of #136705 - compiler-errors:edition-library, r=jhprattJubilee-152/+156
Some miscellaneous edition-related library tweaks Some library edition tweaks that can be done separately from upgrading the whole standard library to edition 2024 (which is blocked on getting the submodules upgraded, for example)
2025-02-10Rollup merge of #136552 - ChrisDenton:option-find-handle, r=Mark-SimulacrumJubilee-10/+6
Use an `Option` for `FindNextFileHandle` in `ReadDir` instead of `INVALID_FILE_HANDLE` sentinel value Sometimes we store an invalid handle when we don't want to return an error. We then check the handle before use in order to avoid actually using the invalid handle. However, using an `Option` for this is better and avoids us forgetting to check the handle is valid. This was noticed due to us closing the handle without checking for validity: https://github.com/rust-lang/rust/blob/bd6a6777f5cbbec549f123995026cef76d1e6b84/library/std/src/sys/pal/windows/fs.rs#L148-L151
2025-02-10Rollup merge of #136487 - marcoieni:disable-mysql-systemctl, r=Mark-SimulacrumJubilee-0/+3
ci: stop mysql before removing it try-job: aarch64-gnu
2025-02-10Rollup merge of #136472 - jieyouxu:pass-stage, r=Mark-SimulacrumJubilee-38/+41
[`compiletest`-related cleanups 2/7] Feed stage number to compiletest directly Reference for overall changes: https://github.com/rust-lang/rust/pull/136437 Part **2** of **7** of the *`compiletest`-related cleanups* PR series. ### Summary - Pass stage number via new `--stage` compiletest flag directly from bootstrap, instead of deriving that info in compiletest by doing gymnastics on `--stage-id`. - Just a cleanup, should have no functional changes. r? bootstrap
2025-02-10Rollup merge of #136353 - purplesyringa:libtest-instant-wasm, r=Mark-SimulacrumJubilee-2/+3
fix(libtest): Enable Instant on Emscripten targets `Instant::now()` works correctly on Emscripten since https://github.com/rust-lang/libc/pull/3962. All wasm-family targets with OS support can now handle instants. Improves #131738. ~~This changes the behavior of libtest on `unknown-unknown`/`unknown-none` wasm targets, but as far as I can see, libtest doesn't support them anyway. (Can anyone double-check?)~~ UPD: this patch no longer affects `unknown-unknown` targets. ``@rustbot`` label +A-libtest +T-testing-devex +O-emscripten +O-wasm -needs-triage
2025-02-10Rollup merge of #136228 - hkBst:patch-28, r=Mark-SimulacrumJubilee-3/+3
Simplify Rc::as_ptr docs + typo fix
2025-02-10Rollup merge of #136201 - davidv1992:eliminate-field-offset-alt, ↵Jubilee-35/+20
r=Mark-Simulacrum Removed dependency on the field-offset crate, alternate approach This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance. r? ``@Mark-Simulacrum``
2025-02-10Rollup merge of #136053 - Zalathar:defer-counters, r=saethlinJubilee-664/+355
coverage: Defer part of counter-creation until codegen Follow-up to #135481 and #135873. One of the pleasant properties of the new counter-assignment algorithm is that we can stop partway through the process, store the intermediate state in MIR, and then resume the rest of the algorithm during codegen. This lets it take into account which parts of the control-flow graph were eliminated by MIR opts, resulting in fewer physical counters and simpler counter expressions. Those improvements end up completely obsoleting much larger chunks of code that were previously responsible for cleaning up the coverage metadata after MIR opts, while also doing a more thorough cleanup job. (That change also unlocks some further simplifications that I've kept out of this PR to limit its scope.)
2025-02-10Auto merge of #136803 - lnicola:sync-from-ra, r=lnicolabors-3895/+5673
Subtree update of `rust-analyzer` r? `@ghost`
2025-02-10Bump `cc` to v1.2.13 for the compiler workspaceclubby789-4/+4
2025-02-10ignore win_delete_self test in MiriRalf Jung-0/+1
2025-02-10remove outdated *First autodiff variants for higher-order adManuel Drehwald-22/+6
2025-02-10move second opt run to lto phase and cleanup codeManuel Drehwald-54/+75
2025-02-10Merge pull request #19126 from lnicola/sync-from-rustLaurențiu Nicola-41322/+73484
minor: Sync from downstream
2025-02-10Bump rustc cratesLaurențiu Nicola-17/+18
2025-02-10Merge from rust-lang/rustLaurențiu Nicola-41304/+73465
2025-02-10Preparing for merge from rust-lang/rustLaurențiu Nicola-1/+1
2025-02-10Auto merge of #134740 - Flakebi:amdgpu-target, r=workingjubileebors-10/+220
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: https://github.com/rust-lang/compiler-team/issues/823 Tracking issue: #135024 Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
2025-02-09compiler: remove `abi`-specific `extern "{abi}"` suggestionsJubilee Young-69/+14
These are either residue of a long-term migration away from something, or are simply trying too hard to be specifically useful: nearest-match suggestions for ABI strings should handle this.