https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.60.0 2021-12-13T00:00:00+00:00 2021-12-13T00:00:00+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2021-12-13T00:00:00+00:00 urn:sha1:3f2a1c9c1726d4d93e3433303262e44faa5910e9 The resulting profile will include the crate name and will be stored in the `--out-dir` directory. This implementation makes it convenient to use LLVM time trace together with cargo, in the contrast to the previous implementation which would overwrite profiles or store them in `.cargo/registry/..`. 2021-09-30T17:41:32+00:00 Camille GILLOT gillot.camille@gmail.com 2021-09-24T19:06:11+00:00 urn:sha1:ea6b7996b570538393bf9e4575553f739fa5af36 2021-07-06T17:40:21+00:00 bjorn3 bjorn3@users.noreply.github.com 2021-07-06T17:40:21+00:00 urn:sha1:25e45baf55280eb310cfb182024194c69347c890 2021-06-04T11:20:05+00:00 bjorn3 bjorn3@users.noreply.github.com 2021-05-29T16:14:30+00:00 urn:sha1:435b540607554ea11fa3d3c71b8b6b17df75f806 2021-05-14T12:58:58+00:00 bors bors@rust-lang.org 2021-05-14T12:58:58+00:00 urn:sha1:75da570d784a798a34ff1e5048cd9a6a2fb23170 Use the object crate for metadata reading This allows sharing the metadata reader between cg_llvm, cg_clif and other codegen backends. This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format, but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)` The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata, but I am not certain. If this happens to not be the case, I could keep using LLVM for reading dylib metadata. Marked as WIP for a perf run and as it is based on #83637. 2021-05-13T11:03:59+00:00 bjorn3 bjorn3@users.noreply.github.com 2021-05-13T11:03:59+00:00 urn:sha1:6381aaf8ae2df01cdb70b6f3123153cf4f1e03cd 2021-05-02T16:00:20+00:00 bjorn3 bjorn3@users.noreply.github.com 2021-03-30T10:54:42+00:00 urn:sha1:18d1b3f3ebb8a5c5fb9a58122f6eaab63d09ec4e 2020-10-10T17:00:51+00:00 bjorn3 bjorn3@users.noreply.github.com 2020-10-10T15:59:16+00:00 urn:sha1:aa51449af43c428fd8ddbdc8dd53a11c3741f3ec 2020-07-10T11:39:28+00:00 Tamir Duberstein tamird@gmail.com 2020-07-07T15:12:44+00:00 urn:sha1:62cf767a4a39b47677d18110359d9e7152dc9d1c Other terms are more inclusive and precise. 2020-04-28T09:41:12+00:00 Camille GILLOT gillot.camille@gmail.com 2020-04-03T15:15:02+00:00 urn:sha1:0b789834ddfd96bfa7c28524d8d43535cb0fd7dc