https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.80.0 2024-05-23T18:58:30+00:00 2024-05-23T18:58:30+00:00 Augie Fackler augie@google.com 2024-05-23T18:58:30+00:00 urn:sha1:de8200c5a441079cfaadd383a8b6897155bfa2c6 If we don't do this, some versions of LLVM (at least 17, experimentally) will double-emit some error messages, which is how I noticed this. Given that it seems to be costing some extra work, let's only request the summary bitcode production if we'll actually bother writing it down, otherwise skip it. 2024-05-22T18:04:22+00:00 Augie Fackler augie@google.com 2024-01-19T19:42:43+00:00 urn:sha1:aa91871539ca518e81af58485df895f8db30496a Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area. I talked some to @teresajohnson about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world. Per @dtolnay, you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written. 2024-03-17T17:11:04+00:00 Josh Stone jistone@redhat.com 2024-03-16T01:43:19+00:00 urn:sha1:29430554f65619007f004e7941b7c2efb6465dbf 2024-03-07T15:24:48+00:00 Augie Fackler augie@google.com 2024-03-07T14:49:15+00:00 urn:sha1:ef626d772f7ee9ddba526b0693993f6479ee5c14 @rustbot label: +llvm-main 2024-03-06T05:15:56+00:00 Jubilee Young workingjubilee@gmail.com 2024-03-06T04:04:24+00:00 urn:sha1:23623a08d6a181864a7b8609682eee27534b12f4 C++ style guides I am aware of recommend specifically preferring = syntax for any classes with fairly obvious constructors[^0] that do not perform any complicated logic in their constructor. I contend that all constructors that the `rustc_llvm` code uses qualify. This has only become more common since C++ 17 guaranteed many cases of copy initialization elision. The other detail is that I tried to ask another contributor with infinitely more C++ experience than me (i.e. any) what this constructor syntax was, and they thought it was a macro. I know of no other language that has adopted this same syntax. As the rustc codebase features many contributors experienced in many other languages, using a less... unique... style has many other benefits in making this code more lucid and maintainable, which is something it direly needs. [^0]: e.g. https://abseil.io/tips/88 2024-03-02T02:50:40+00:00 Ramon de C Valle rcvalle@users.noreply.github.com 2024-02-01T21:16:30+00:00 urn:sha1:dee4e02102197adc29be9bf98083297dd3f5e2ed Adds initial support for DataFlowSanitizer to the Rust compiler. It currently supports `-Zsanitizer-dataflow-abilist`. Additional options for it can be passed to LLVM command line argument processor via LLVM arguments using `llvm-args` codegen option (e.g., `-Cllvm-args=-dfsan-combine-pointer-labels-on-load=false`). 2024-02-13T15:07:28+00:00 bors bors@rust-lang.org 2024-02-13T15:07:28+00:00 urn:sha1:eaff1af8fdd18ee3eb05167b2836042b7d4315f6 Update to LLVM 18 LLVM 18 final is planned to be released on Mar 5th. Rust 1.78 is planned to be released on May 2nd. Tested images: dist-x86_64-linux, dist-s390x-linux, dist-aarch64-linux, dist-riscv64-linux, dist-loongarch64-linux, dist-x86_64-freebsd, dist-x86_64-illumos, dist-x86_64-musl, x86_64-linux-integration, test-various, armhf-gnu, i686-msvc, x86_64-msvc, i686-mingw, x86_64-mingw, x86_64-apple-1, x86_64-apple-2, dist-aarch64-apple r? `@ghost` 2024-02-13T09:33:40+00:00 Nikita Popov npopov@redhat.com 2024-01-17T14:05:18+00:00 urn:sha1:a911c8ce23a29a0721fb02ff90368143e764de9c This method is now available in upstream LLVM \o/ 2024-02-13T00:13:09+00:00 Augie Fackler augie@google.com 2024-02-13T00:13:09+00:00 urn:sha1:9d1bd2e067a82d6a2552b3705bbe6f256e9bde0c Should be no functional change. @rustbot label: +llvm-main 2024-02-06T09:44:40+00:00 klensy klensy@users.noreply.github.com 2024-02-06T09:44:40+00:00 urn:sha1:ca35cfb6defe6bdec8ab0419aa682db780142fb7