https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=lcnr/rustc-dev-guide 2025-08-12T16:20:24+00:00 2025-08-12T16:20:24+00:00 bors bors@rust-lang.org 2025-08-12T16:20:24+00:00 urn:sha1:8e62bfd311791bfd9dca886abdfbab07ec54d8b4 Make no_mangle on foreign items explicit instead of implicit for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it. I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :) Builds on rust-lang/rust#144655 which should merge first. 2025-08-12T10:07:14+00:00 Jana Dönszelmann jana@donsz.nl 2025-07-29T18:51:46+00:00 urn:sha1:7aa8707639ede0605d7182bc13047b6e4549e5b1 2025-08-11T21:31:07+00:00 Mads Marquart mads@marquart.dk 2025-08-11T18:46:31+00:00 urn:sha1:1d1316240f0fa60b042bcead8ab29609c0090489 The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me, but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. Since we now pass the SDK root via the environment variable SDKROOT, compiler drivers that don't support it can just ignore it. Similarly, since we only warn when xcrun fails, users that expect their compiler driver to provide the SDK location can do so now. 2025-08-11T20:29:01+00:00 Mads Marquart mads@marquart.dk 2025-08-11T19:42:38+00:00 urn:sha1:f4a911031daf366aa621871a065390688efbaf5d To allow using zig-cc or similar as the compiler driver. 2025-08-11T20:29:00+00:00 Mads Marquart mads@marquart.dk 2025-08-11T20:29:00+00:00 urn:sha1:1cc44bfd22f4db5bcf3921f4a8b64df4e9cf4124 This is more in-line with what Apple's tooling expects, and allows us to better support custom compiler drivers (such as certain Homebrew and Nixpkgs compilers) that prefer their own `-isysroot` flag. Effectively, we now invoke the compiler driver as-if it was invoked as `xcrun -sdk $sdk_name $tool`. 2025-08-11T19:33:34+00:00 Mads Marquart mads@marquart.dk 2025-08-11T19:28:46+00:00 urn:sha1:1dc37df51476b568b1fa94db14a7669656989862 Reduce indentation and avoid needless checks (checking the target OS and vendor is unnecessary). 2025-08-09T03:58:43+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-08-09T03:58:43+00:00 urn:sha1:2053728d8128998a75c754ed87768f4cdef42938 Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code `STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program termination, e.g. by abort(). Emit a special diagnostic to let people know that this most likely doesn't indicate a stack buffer overrun. This doesn't look up the crash report in the event log to determine what the fast fail error code is. This is due to the way crashes are logged: When a process crash happens, the system logs an "Application Error" event, which contains the exit code and the process ID, but not the fast fail error code. A second event by Windows Error Reporting does contain that fast fail code, but not the process ID - but that event is not emitted at process exit, but when WER has dealt with it (on my system, it happens roughly two seconds later), so querying the code would have to read the `IntegratorReportId`, wait two seconds or potentially longer for the WER event with the same `ReportID`, and read out the code. (Also, that second event doesn't happen if WER is disabled.) Fixes rust-lang/rust#100519. 2025-08-08T11:29:46+00:00 Mads Marquart mads@marquart.dk 2025-03-01T02:10:05+00:00 urn:sha1:d434cae18f92d8a5ef8996fb579e2c11efbaa2cb 2025-08-07T22:16:53+00:00 George Tokmaji tokmajigeorge@gmail.com 2025-05-31T19:18:41+00:00 urn:sha1:b60f75c9261e0968fbb6f3aa435660db189e0ab5 used for stack buffer overruns if link.exe exits with that exit code `STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program termination, e.g. by abort(). Emit a special diagnostic to let people know that this most likely doesn't indicate a stack buffer overrun. 2025-08-07T14:30:43+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-08-07T14:30:43+00:00 urn:sha1:186cef0f517816cc655316691ebea665dbdb3e49 The metadata symbol must not be encoded in the crate metadata, and must be exported from proc-macros. Handling the export of the metadata symbol in exported_symbols handles both things at once without requiring manual fixups elsewhere.