solver comments + remove `TyCtxt::evaluate_goal`
from the `RustcContributor::explore` session yesterday.
This also removes `TyCtxt::evaluate_goal` because to canonicalize you have to use an `InferCtxt` anyways at which point we should just always get people to use `evaluate_root_goal`.
r? ``@spastorino``
Revisit fix_is_ci_llvm_available logic
Fixes#107225
Now `supported_platforms` has a knowledge whether llvm asserts artifacts are available for particular host triple.
``@jyn514`` ``@albertlarsan68`` PTAL
Replace format flags u32 by enums and bools.
This gets rid of the `flags: u32` field where each bit has a special meaning, and replaces it by simple enums and booleans.
Part of #99012
rustdoc: Collect "rustdoc-reachable" items during early doc link resolution
This pass only needs to know about visibilities, attributes and reexports, so it can be run early, similarly to `compute_effective_visibilities` in rustc.
Results of this pass can be used to prune the list of extern impls early thus improving performance of https://github.com/rust-lang/rust/pull/94857.
rustdoc: use smarter encoding for playground URL
The old way would compress okay with DEFLATE, but this version makes uncompressed docs smaller, which matters for memory usage and stuff like `cargo doc`.
Try it out: <https://play.rust-lang.org/?code=fn+main()+{%0Alet+mut+v+=+Vec::new();%0Av.push(1+/+1);%0Aprintln!(%22{}%22,+v[0]);%0A}>
In local testing, this change shrinks sample pages by anywhere between 4.0% and 0.031%
$ du -b after.dir/std/vec/struct.Vec.html before.dir/std/vec/struct.Vec.html
759235 after.dir/std/vec/struct.Vec.html
781842 before.dir/std/vec/struct.Vec.html
100*((759235-781842)/781842)=-2.8
$ du -b after.dir/std/num/struct.Wrapping.html before.dir/std/num/struct.Wrapping.html
3194173 after.dir/std/num/struct.Wrapping.html
3204351 before.dir/std/num/struct.Wrapping.html
100*((3194173-3204351)/3204351)=-0.031
$ du -b after.dir/std/keyword.match.html before.dir/std/keyword.match.html
8151 after.dir/std/keyword.match.html
8495 before.dir/std/keyword.match.html
100*((8151-8495)/8495)=-4.0
Gzipped tarball sizes seem shrunk, but not by much.
du -s before.tar.gz after.tar.gz
69600 before.tar.gz
69480 after.tar.gz
100*((69480-69600)/69600)=-0.17
rustc_metadata: Fix `encode_attrs`
This function didn't do what the authors intended it to do.
- Due to `move` in the closure `is_public` wasn't captured by mutalbe reference and wasn't used as a cache.
- Due to iterator cloning all the `should_encode_attr` logic run for the second time to calculate `may_have_doc_links`
This PR fixes these issues, and calculates all the needed attribute flags in one go.
(Noticed while implementing https://github.com/rust-lang/rust/pull/107136.)
core: Support variety of atomic widths in width-agnostic functions
Before this change, the following functions and macros were annotated with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:
* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`
However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it).
This change fixes that by removing the `"8"` argument from annotations, which results in accepting the whole variety of widths.
Fixes#106845Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Sync rustc_codegen_cranelift
For cg_clif itself there have been a couple of bug fixes since the last sync, a Cranelift update and implemented all remaining simd platform intrinsics used by `std::simd`. (`std::arch` still misses a lot though) Most of the diff is from reworking of the cg_clif build system though.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
make `output_filenames` a real query
part of #105462
This may be a perf regression and is not obviously the right way forward. We may store this information in the resolver after freezing it for example.
