minor: Sync from downstream #19126
Merged
minor: Sync from downstream #19126
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reexport likely/unlikely in std::hint Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval Tracking issue: #26179
Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase Part of #132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro - Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro. - Skipped `.md` files and test files to avoid unnecessary changes.
Subtree update of `rust-analyzer` r? ``@ghost``
Subtree sync for rustc_codegen_cranelift Nothing too exciting this time, but this includes a fix for a linker hang on Windows: rust-lang/rustc_codegen_cranelift#1554 r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Rollup of 7 pull requests Successful merges: - #133695 (Reexport likely/unlikely in std::hint) - #135330 (Respect --sysroot for rustc -vV and -Cpasses=list) - #135333 (Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase) - #135741 (Recognise new IPv6 documentation range from IETF RFC 9637) - #135770 (Update contributing docs for submodule/subtree changes) - #135775 (Subtree update of `rust-analyzer`) - #135776 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup
Enable `unreachable_pub` lint in core This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) as warn in `core`, `rtstartup` and `panic_unwind`. The motivation is similar to the compiler [MCP: Enable deny(unreachable_pub) on `rustc_*` crates](rust-lang/compiler-team#773 (comment)) : > "Where is this thing used?" is a question I ask all the time when reading unfamiliar code. Because of this, I generally find it annoying when things are marked with a more permissive visibility than necessary. "This thing marked pub, which other crates is it used in? Oh, it's not used in any other crates." Another motivation is to help to lint by utilizing it in-tree and seeing it's limitation in more complex scenarios. The diff was mostly generated with `./x.py fix --stage 1 library/core/ -- --broken-code`, as well as manual edits for code in macros, generated code and other targets. r? libs
Outline panicking code for `LocalKey::with` See rust-lang/rust#115491 for prior related modifications. https://godbolt.org/z/MTsz87jGj shows a reduction of the code size for TLS accesses.
CI: split x86_64-msvc job using windows 2025 try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: dist-x86_64-msvc
Rework dyn trait lowering to stop being so intertwined with trait alias expansion This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in rust-lang/rust#133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable. In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards. Please review this with whitespace disabled. r? lcnr
remove support for the (unstable) #[start] attribute As explained by `@Noratrieb:` `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction. I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple: - `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail) - `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways* `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place. Note that this feature has **not** been RFCed in the first place. *This comment was posted [in May](rust-lang/rust#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang/rust#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
Update our range `assume`s to the format that LLVM prefers I found out in llvm/llvm-project#123278 (comment) that the way I started emitting the `assume`s in #109993 was suboptimal, and as seen in that LLVM issue the way we're doing it -- with two `assume`s sometimes -- can at times lead to CVP/SCCP not realize what's happening because one of them turns into a `ne` instead of conveying a range. So this updates how it's emitted from ``` assume( x >= LOW ); assume( x <= HIGH ); ``` or ``` // (for ranges that wrap the range) assume( (x <= LOW) | (x >= HIGH) ); ``` to ``` assume( (x - LOW) <= (HIGH - LOW) ); ``` so that we don't need multiple `icmp`s nor multiple `assume`s for a single value, and both wrappping and non-wrapping ranges emit the same shape. (And we don't bother emitting the subtraction if `LOW` is zero, since that's trivial for us to check too.)
Properly record metavar spans for other expansions other than TT This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result. Fixes #132908 Alternative to #133270 cc `@ehuss` cc `@petrochenkov`
…compiler-errors Skip `if-let-rescope` lint unless requested by migration Tracked by #124085 Related to rust-lang/rust#131984 (comment) Given that `if-let-rescope` is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run. cc `@Kobzol` `@rylev` `@traviscross` I propose a `rust-timer` run to measure how much performance that we can recover from the mitigation. 🙇
show linker output even if the linker succeeds Show stderr and stderr by default, controlled by a new `linker_messages` lint. fixes rust-lang/rust#83436. fixes rust-lang/rust#38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134 <!-- try-job: dist-x86_64-msvc --> try-job: aarch64-apple r? `@bjorn3`
Get rid of `mir::Const::from_ty_const` This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts. All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those. For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
Fix tests on LLVM 20 For sparcv8plus.rs, duplicate the test for LLVM 19 and LLVM 20. LLVM 20 resolves one of the FIXME in the test. For x86_64-bigint-add.rs split the check lines for LLVM 19 and LLVM 20. The difference in codegen here is due to a difference in unroll factor, which I believe is not what the test is interested in. Fixes rust-lang/rust#132957. Fixes rust-lang/rust#133754.
…eywiser Windows x86: Change i128 to return via the vector ABI Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: rust-lang/rust#134288 (does not fix) [1] try-job: x86_64-msvc try-job: x86_64-msvc-ext1 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2
…jhpratt [cfg_match] Document the use of expressions. cc #115585 Adds documentation to this new feature introduced in #133720.
Rename `Piece::String` to `Piece::Lit` This renames Piece::String to Piece::Lit to avoid shadowing std::string::String and removes "pub use Piece::*;".
…asper Add mermaid graphs of NLL regions and SCCs to polonius MIR dump This PR expands the polonius MIR dump again with a couple of mermaid charts ported from the graphviz version: - the NLL region graph - and the NLL SCCs I still have done zero visual design on this until now, but [here's](https://gistpreview.github.io/?fbbf900fed2ad21108c7ca0353456398) how it looks (i.e. still bad) just to give an idea of the result. r? `````@matthewjasper````` (feel free to reassign) or anyone
Update books ## rust-lang/book 3 commits in 82a4a49789bc96db1a1b2a210b4c5ed7c9ef0c0d..fa312a343fbff01bc6cef393e326817f70719813 2025-01-22 17:14:29 UTC to 2025-01-22 15:09:26 UTC - chore: reformat src with dprint (rust-lang/book#4211) - Redirects: get rid of the weird gap in Ch. 20 sections! (rust-lang/book#4209) - Document that `use` is also for `precise capturing` (rust-lang/book#4210) ## rust-lang/edition-guide 1 commits in d56e0f3a0656b7702ca466d4b191e16c28262b82..4ed5a1a4a2a7ecc2e529a5baaef04f7bc7917eda 2025-01-21 21:39:56 UTC to 2025-01-21 21:39:56 UTC - Add alternatives for static-mut-refs (rust-lang/edition-guide#354) ## rust-lang/nomicon 3 commits in 625b200e5b33a5af35589db0bc454203a3d46d20..bc2298865544695c63454fc1f9f98a3dc22e9948 2025-01-23 19:01:24 UTC to 2025-01-20 14:37:52 UTC - corrected grammatical error. (rust-lang/nomicon#477) - Remove `#![start]` attribute (rust-lang/nomicon#478) - Update guidance on uninitialized fields to use &raw mut instead of addr_of_mut! (rust-lang/nomicon#476) ## rust-lang/reference 10 commits in 293af991003772bdccf2d6b980182d84dd055942..93b921c7d3213d38d920f7f905a3bec093d2217d 2025-01-25 21:59:01 UTC to 2025-01-14 17:28:04 UTC - distinct 'static' items never overlap (rust-lang/reference#1657) - Change `'_static` to `'static` as an invalid lifetime parameter name (rust-lang/reference#1721) - reword reference about inert attributes (rust-lang/reference#1719) - Provide a better error message for broken links in mdbook-spec (rust-lang/reference#1716) - Remove unstable vectorcall (rust-lang/reference#1717) - Move the function pointer example (rust-lang/reference#1718) - references and Box must be non-null (rust-lang/reference#1715) - Fix filename for theme customization (rust-lang/reference#1711) - Add Identifier Syntax to Several Chapters (rust-lang/reference#1597) - move r[rules] to the left of the main body, using a grid (rust-lang/reference#1710)
…-add, r=workingjubilee ABI-required target features: warn when they are missing in base CPU Part of rust-lang/rust#135408: instead of adding ABI-required features to the target we build for LLVM, check that they are already there. Crucially we check this after applying `-Ctarget-cpu` and `-Ctarget-feature`, by reading `sess.unstable_target_features`. This means we can tweak the ABI target feature check without changing the behavior for any existing user; they will get warnings but the target features behave as before. The test changes here show that we are un-doing the "add all required target features" part. Without the full #135408, there is no way to take a way an ABI-required target feature with `-Ctarget-cpu`, so we cannot yet test that part. Cc ``@workingjubilee``
Refactor FnKind variant to hold &Fn Pulling the change suggested in #128045 to reduce the impact of changing `Fn` item. r? `@oli-obk`
Rollup of 7 pull requests Successful merges: - #135625 ([cfg_match] Document the use of expressions.) - #135902 (Do not consider child bound assumptions for rigid alias) - #135943 (Rename `Piece::String` to `Piece::Lit`) - #136104 (Add mermaid graphs of NLL regions and SCCs to polonius MIR dump) - #136143 (Update books) - #136147 (ABI-required target features: warn when they are missing in base CPU) - #136164 (Refactor FnKind variant to hold &Fn) r? `@ghost` `@rustbot` modify labels: rollup
Subtree update of `rust-analyzer` r? `@ghost`
Rollup of 9 pull requests Successful merges: - #136121 (Deduplicate operand creation between scalars, non-scalars and string patterns) - #136134 (Fix SIMD codegen tests on LLVM 20) - #136153 (Locate asan-odr-win with other sanitizer tests) - #136161 (rustdoc: add nobuild typescript checking to our JS) - #136166 (interpret: is_alloc_live: check global allocs last) - #136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items) - #136170 (Reject unsound toggling of Arm atomics-32 target feature) - #136176 (Render pattern types nicely in mir dumps) - #136186 (uefi: process: Fix args) r? `@ghost` `@rustbot` modify labels: rollup
Merge `PatKind::Path` into `PatKind::Expr` Follow-up to #134228 We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after #134228, so I'm removing it now.
tests: Port `translation` to rmake.rs
Part of #121876.
This PR partially supersedes #129011 and is co-authored with `@Oneirical.`
## Summary
This PR ports `tests/run-make/translation` to rmake.rs. Notable changes from the Makefile version include:
- We now actually fail if the rustc invocations fail... The Makefile did not have `SHELL=/bin/bash -o pipefail`, so all the piped rustc invocations to grep vacuously succeeded, even if the broken ftl test case actually regressed over time and ICEs on current master.
- That test case is converted to assert it fails with a FIXME backlinking to #135817.
- The test coverage is expanded to not ignore windows. Instead, the test now uses symlink capability detection to gate test execution.
- Added some backlinks to relevant tracking issues and the initial translation infra implementation PR.
## Review advice
Best reviewed commit-by-commit.
r? compiler
try-job: aarch64-apple
try-job: i686-mingw
miri: optimize zeroed alloc When allocating zero-initialized memory in MIR interpretation, rustc allocates zeroed memory, marks it as initialized and then re-zeroes it. Remove the last step. I don't expect this to have much of an effect on performance normally, but in my case in which I'm creating a large allocation via mmap it gets in the way.
Target option to require explicit cpu Some targets have many different CPUs and no generic CPU that can be used as a default. For these targets, the user needs to explicitly specify a CPU through `-C target-cpu=`. Add an option for targets and an error message if no CPU is set. This affects the proposed amdgpu and avr targets. amdgpu tracking issue: #135024 AVR MCP: rust-lang/compiler-team#800
… enabled Similar to how the alignment is already checked, this adds a check for null pointer dereferences in debug mode. It is implemented similarly to the alignment check as a MirPass. This is related to a 2025H1 project goal for better UB checks in debug mode: rust-lang/rust-project-goals#177.
…e,aDotInTheVoid [rustdoc] Add `--extract-doctests` command-line flag Part of rust-lang/rust#134529. It was discussed with the Rust-for-Linux project recently that they needed a way to extract doctests so they can modify them and then run them more easily (look for "a way to extract doctests" [here](Rust-for-Linux/linux#2)). For now, I output most of `ScrapedDoctest` fields in JSON format with `serde_json`. So it outputs the following information: * filename * line * langstr * text cc `@ojeda` r? `@notriddle`
…r=jieyouxu Compiler: Finalize dyn compatibility renaming Update the Reference link to use the new URL fragment from rust-lang/reference#1666 (this change has finally hit stable). Fixes a FIXME. Follow-up to #130826. Part of #130852. ~~Blocking it on #133372.~~ (merged) r? ghost
Improve documentation when adding a new target rust-lang/rust#133631 (comment) shows that it can be a bit difficult process-wise to add a new target. I've added a bit of text to the docs, suggesting that users add the target defintion/spec first, and later work on `std` support. I also found that we have two places where we document how to add a new target. I've linked these for now, but they should probably be merged somehow in the future. `@rustbot` label A-docs r? compiler CC `@workingjubilee` who's worked a lot on target specs IIRC.
Support clobber_abi in BPF inline assembly This supports [`clobber_abi`](https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers) which is one of the requirements of stabilization mentioned in the tracking Issue for `asm_experimental_arch` (#93335). Refs: [Section 1.1 "Registers and calling convention" in BPF ABI Recommended Conventions and Guidelines v1.0](https://github.com/torvalds/linux/blob/v6.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention) > R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. cc `@alessandrod` `@dave-tucker` `@tamird` `@vadorovsky` (target maintainers mentioned in platform support document which will be added by rust-lang/rust#135107) r? `@Amanieu` `@rustbot` label +O-eBPF +A-inline-assembly
Insert null checks for pointer dereferences when debug assertions are enabled
Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a `MirPass`.
This inserts checks in the same places as the `CheckAlignment` pass and additionally
also inserts checks for `Borrows`, so code like
```rust
let ptr: *const u32 = std::ptr::null();
let val: &u32 = unsafe { &*ptr };
```
will have a check inserted on dereference. This is done because null references
are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`,
the exact requirement is that the final reference must be aligned. This is something to
consider further enhancements of the alignment check.
For now this is implemented as a separate `MirPass`, to make it easy to disable
this check if necessary.
This is related to a 2025H1 project goal for better UB checks in debug
mode: rust-lang/rust-project-goals#177.
r? `@saethlin`
Rollup of 9 pull requests Successful merges: - #134531 ([rustdoc] Add `--extract-doctests` command-line flag) - #135860 (Compiler: Finalize dyn compatibility renaming) - #135992 (Improve documentation when adding a new target) - #136194 (Support clobber_abi in BPF inline assembly) - #136325 (Delay a bug when indexing unsized slices) - #136326 (Replace our `LLVMRustDIBuilderRef` with LLVM-C's `LLVMDIBuilderRef`) - #136330 (Remove unnecessary hooks) - #136336 (Overhaul `rustc_middle::util`) - #136341 (Remove myself from vacation) r? `@ghost` `@rustbot` modify labels: rollup
…ratrieb tests: Port `symbol-mangling-hashed` to rmake.rs Part of #121876. This PR supersedes #128567 and is co-authored with `@lolbinarycat.` ### Summary This PR ports `tests/run-make/symbol-mangling-hashed` to rmake.rs. Notable differences when compared to the Makefile version includes: - It's no longer limited to linux + x86_64 only. In particular, this now is exercised on darwin and windows (esp. msvc) too. - The test uses `object` crate to be more precise in the filtering, and avoids relying on parsing the human-readable `nm` output for *some* `nm` in the given environment (which isn't really a thing on msvc anyway, and `llvm-nm` doesn't handle msvc dylibs AFAICT). - Dump the symbols satisfying various criteria on test failure to make it hopefully less of a pain to debug if it ever fails in CI. ### Review advice - Best reviewed commit-by-commit. - I'm not *super* sure about the msvc logic, would benefit from a MSVC (PE/COFF) expert taking a look. --- try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: i686-mingw try-job: x86_64-mingw-1 try-job: x86_64-apple-1 try-job: aarch64-apple try-job: test-various
ci: use ubuntu 24 on free runners try-job: aarch64-gnu try-job: aarch64-gnu-debug
ci: refactor how directories are removed in free-disk-space disk try-job: aarch64-gnu
…,saethlin Target modifiers (special marked options) are recorded in metainfo Target modifiers (special marked options) are recorded in metainfo and compared to be equal in different linked crates. PR for this RFC: rust-lang/rfcs#3716 Option may be marked as `TARGET_MODIFIER`, example: `regparm: Option<u32> = (None, parse_opt_number, [TRACKED TARGET_MODIFIER]`. If an TARGET_MODIFIER-marked option has non-default value, it will be recorded in crate metainfo as a `Vec<TargetModifier>`: ``` pub struct TargetModifier { pub opt: OptionsTargetModifiers, pub value_name: String, } ``` OptionsTargetModifiers is a macro-generated enum. Option value code (for comparison) is generated using `Debug` trait. Error example: ``` error: mixing `-Zregparm` will cause an ABI mismatch in crate `incompatible_regparm` --> $DIR/incompatible_regparm.rs:10:1 | LL | #![crate_type = "lib"] | ^ | = help: the `-Zregparm` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: `-Zregparm=1` in this crate is incompatible with `-Zregparm=2` in dependency `wrong_regparm` = help: set `-Zregparm=2` in this crate or `-Zregparm=1` in `wrong_regparm` = help: if you are sure this will not cause problems, use `-Cunsafe-allow-abi-mismatch=regparm` to silence this error error: aborting due to 1 previous error ``` `-Cunsafe-allow-abi-mismatch=regparm,reg-struct-return` to disable list of flags.
…oli-obk fix autodiff compile time regression Tries to fix the regression from rust-lang/rust#133429 Tracking: - rust-lang/rust#124509
Add a couple of missing `ensure_sufficient_stacks` r? `@saethlin` I hope you didn't spend time on this already. (I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it) This PR adds a couple of missing `ensure_sufficient_stack`s: - one in `check_tail_calls` that prevented the #135709 backport on some targets. - after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass. I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to. On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
Explicitly choose x86 softfloat/hardfloat ABI Part of rust-lang/rust#135408: Instead of choosing this based on the target features listed in the target spec, make that choice explicit. All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
…enton Display of integers without raw pointers and without overflowing_literals The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead. The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel. Happy to do the 128-bit version too if such change is welcome.
Shard AllocMap Lock This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in rust-lang/rust#136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too. Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally. r? `@RalfJung`
Upgrade elsa to the newest version. This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows. This was spawned from rust-lang/rust#135870 (comment)
Avoid calling the layout_of query in lit_to_const We got all the information available locally
rustdoc: run css and html minifier at build instead of runtime This way, adding a bunch of comments to the JS files won't make rustdoc slower. Meant to address rust-lang/rust#136161 (comment)
rustdoc: use ThinVec for generic arg parts This reduces the size of both these args, and of path segments, so should measurably help with memory use.
rustbot
added
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.