| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
sync_cg_clif-2025-02-07
|
|
|
|
|
|
sync_cg_clif-2025-01-20
|
|
sync_cg_clif-2025-01-10
|
|
sync_cg_clif-2025-01-05
|
|
|
|
It is treated as a map already. This is using FxIndexMap rather than
UnordMap because the latter doesn't provide an api to pick a single
value iff all values are equal, which each_linked_rlib depends on.
|
|
It is effectively a global resource and the jobserver::Client in Session
was a clone of GLOBAL_CLIENT anyway.
|
|
sync_cg_clif-2024-12-06
|
|
|
|
sync_cg_clif-2024-11-09
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
sync_cg_clif-2024-06-30
|
|
Show files produced by `--emit foo` in json artifact notifications
Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.
Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477
Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: https://github.com/hintron/computer-enhance/issues/35
This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.
Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit #88829 / #89149
|
|
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.
|
|
sync_cg_clif-2024-05-13
|
|
sync_cg_clif-2024-04-23
|
|
|
|
|
|
sync_cg_clif-2024-03-28
|
|
sync_cg_clif-2024-01-26
|
|
To avoid the use of a mutable local variable, and because it reads more
nicely.
|
|
sync_cg_clif-2023-12-31
|
|
|
|
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier
access.
|
|
|
|
sync_cg_clif-2023-10-24
|
|
sync_cg_clif-2023-10-21
|
|
|
|
This removes a bit of global mutable state
|
|
|
|
sync_cg_clif-2023-10-09
|
|
|
|
Removes a piece of mutable state.
Follow up to #114578.
|
|
sync_cg_clif-2023-07-22
|
|
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the
next commit will add another field.
|
|
sync_cg_clif-2023-06-15
|
|
|
|
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
|
|
sync_cg_clif-2023-04-29
|
|
sync_cg_clif-2023-03-15
|
|
|
|
sync_cg_clif-2023-02-09
|
|
sync_cg_clif-2023-01-24
|
|
sync_cg_clif-2022-12-14
|
|
sync_cg_clif-2022-10-23
|
|
sync_cg_clif-2022-08-24
|
