https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=cargo_update 2025-09-21T17:12:18+00:00 2025-09-21T17:12:18+00:00 Ben Kimock kimockb@gmail.com 2025-09-07T16:31:35+00:00 urn:sha1:888679013d1f424adef06267f3630069b4cabd40 2025-08-27T18:25:16+00:00 Jonathan Brouwer jonathantbrouwer@gmail.com 2025-07-16T11:46:08+00:00 urn:sha1:e8d08b5416c0fd159388fe6cdd1a3b43dd759132 2025-07-24T11:04:00+00:00 usamoi usamoi@outlook.com 2025-07-20T13:40:36+00:00 urn:sha1:e31876c143625a23c95bdf342444f1f1f100c57f 2025-06-08T05:34:41+00:00 Ralf Jung post@ralfj.de 2025-05-23T10:44:15+00:00 urn:sha1:b616e1197482f31c0a403d2dac41bb7425cd70f4 also unify error messages that do not seem to have a good reason to be different 2025-05-19T21:36:33+00:00 Andrew Zhogin andrew.zhogin@gmail.com 2025-05-19T14:14:28+00:00 urn:sha1:4a99cbbf6b1e5074017d49a14cf37259d7c82e50 2025-05-19T14:38:07+00:00 Andrew Zhogin andrew.zhogin@gmail.com 2025-05-19T14:14:28+00:00 urn:sha1:61059282eb9ea1f37804790b182e5821337924b4 2025-03-31T07:44:41+00:00 Jakub Beránek berykubik@gmail.com 2025-03-14T10:45:22+00:00 urn:sha1:674a7adf9bd765354f58c50f3632f3410a6ac9f4 2025-03-17T05:49:34+00:00 Andrew Zhogin andrew.zhogin@gmail.com 2025-03-06T22:34:12+00:00 urn:sha1:6ccaea19895cc8c0861f3a8707f888a15f8be3a1 2025-02-26T18:09:51+00:00 Noratrieb 48135649+Noratrieb@users.noreply.github.com 2025-01-18T17:19:42+00:00 urn:sha1:a954c512809a2d6f3e592c0287dbe41264b54808 raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time. 2025-02-21T17:37:03+00:00 Trevor Gross tmgross@umich.edu 2025-01-29T23:54:15+00:00 urn:sha1:1412cfc987b2b6691367c2e7428c083bb207d722 `compiler_builtins` is currently injected as `extern crate compiler_builtins as _`. This has made gating via diagnostics difficult because it appears in the crate graph as a non-private dependency, and there isn't an easy way to differentiate between the injected AST and user-specified `extern crate compiler_builtins`. Resolve this by injecting `compiler_builtins` during postprocessing rather than early in the AST. Most of the time this isn't even needed because it shows up in `std` or `core`'s crate graph, but injection is still needed to ensure `#![no_core]` works correctly. A similar change was attempted at [1] but this encountered errors building `proc_macro` and `rustc-std-workspace-std`. Similar failures showed up while working on this patch, which were traced back to `compiler_builtins` showing up in the graph twice (once via dependency and once via injection). This is resolved by not injecting if a `#![compiler_builtins]` crate already exists. [1]: https://github.com/rust-lang/rust/pull/113634