https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.83.0 2024-10-12T21:00:56+00:00 2024-10-12T21:00:56+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-10-12T21:00:56+00:00 urn:sha1:663da008760a0f6d38dbd5e7db4c9bb67fa64798 Don't assume traits used as type are trait objs in 2021 edition Fixes #127548 When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case. This PR fixes the bug where you don't need a trait object, so the error message was changed to: ``` error[E0782]: expected a type, found a trait ``` Also fixes some ICEs: Fixes https://github.com/rust-lang/rust/issues/120241 Fixes https://github.com/rust-lang/rust/issues/120482 Fixes https://github.com/rust-lang/rust/issues/125512 2024-10-12T21:00:55+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-10-12T21:00:55+00:00 urn:sha1:57be141f8a03edd6236dc00a3772fc27673a64c3 Check ABI target compatibility for function pointers Tracking issue: https://github.com/rust-lang/rust/issues/130260 Related tracking issue: #87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [x] Should this report a future incompatibility warning like #87678 ? * [ ] Is this the best place to perform the check? 2024-10-11T21:32:56+00:00 Jed Brown jed@jedbrown.org 2024-01-06T04:04:41+00:00 urn:sha1:0d8a978e8a55b08778ec6ee861c2c5ed6703eb6c Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) + c`, to be fused if the code generator determines that (i) the target instruction set has support for a fused operation, and (ii) that the fused operation is more efficient than the equivalent, separate pair of `mul` and `add` instructions. https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic MIRI support is included for f32 and f64. The codegen_cranelift uses the `fma` function from libc, which is a correct implementation, but without the desired performance semantic. I think this requires an update to cranelift to expose a suitable instruction in its IR. I have not tested with codegen_gcc, but it should behave the same way (using `fma` from libc). 2024-10-11T15:36:04+00:00 VulnBandit 183613941+VulnBandit@users.noreply.github.com 2024-10-04T14:10:28+00:00 urn:sha1:9a2772e1c2d6e770e13716d4691bc0a943cd7d61 2024-10-11T13:11:13+00:00 bors bors@rust-lang.org 2024-10-11T13:11:13+00:00 urn:sha1:f4966590d8edd5f493a1aab04016b94a75494329 Retire the `unnamed_fields` feature for now `#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature. However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly. Fixes #117942 Fixes #121161 Fixes #121263 Fixes #121299 Fixes #121722 Fixes #121799 Fixes #126969 Fixes #131041 Tracking: * https://github.com/rust-lang/rust/issues/49804 [^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields [^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108 2024-10-10T20:00:50+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-10-10T20:00:50+00:00 urn:sha1:fa3dff3e2436e9323004c3e960098e4acba964e1 Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible" Follow-up to #130826. Part of #130852. 1. 1st commit: Fix stupid oversights. Should've been part of #130826. 2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide. 3. 3rd commit: Apply the renaming to all UI tests (contents and paths). 2024-10-10T18:46:51+00:00 Michael Goulet michael@errs.io 2024-09-29T17:49:53+00:00 urn:sha1:322c4bdac595e7689dcf08b847d0bd4d82a4bad9 2024-10-10T18:46:51+00:00 Michael Goulet michael@errs.io 2024-09-29T17:49:32+00:00 urn:sha1:36076ecdc726c4e1104e70df2d142f39501a4f48 2024-10-10T18:46:48+00:00 Michael Goulet michael@errs.io 2024-09-29T17:41:13+00:00 urn:sha1:a7dc98733da8b84cfc21a538541a41803c4529a0 2024-10-09T22:57:59+00:00 León Orell Valerian Liehr me@fmease.dev 2024-10-09T16:37:30+00:00 urn:sha1:2e7a52b22fe222316a48093547f6312252c20f0f