librustdoc: Use `pulldown-cmark-escape` for HTML escaping
Implementation of `@notriddle` 's [suggestion](https://github.com/rust-lang/rust/pull/137274#issuecomment-2669001585).
Somewhat related to #137274 , but the two PRs should be complementary.
Local perf results look like a nice improvement! (so would love a perf run on the CI)
Make fewer crates depend on `rustc_ast_ir`
I think it simplifies the crate graph and also exposes people less to confusion if downstream crates don't interact with `rustc_ast_ir` directly and instead just use its functionality reexported through more familiar paths.
r? oli-obk since you introduced ast-ir
Update `minifier-rs` version to `0.3.5`
Encountered a bug around handling of `*` which blocked me for something I'm working on.
Also includes multiple fixes from ```@notriddle.```
r? ```@notriddle```
I had forgotten that error_index_generator is using mdbook. This moves
it to be part of the rustbook workspace so that it can share the
dependency with rustbook.
Replace some u64 hashes with Hash64
I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.
This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.
Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
chore: update rustc-hash 2.1.0 to 2.1.1
This PR updates the rustc-hash crate to include a palliative fix for #135477.
The discussion for this can be found in the issue and on https://github.com/rust-lang/rustc-hash/pull/55.
This PR is the output of running `cargo +nightly update rustc-hash@2.1.0`. I ran all tests locally and they all seem to pass, with the exception of `tests/ui/process/nofile-limit.rs` which always fails on my setup.
`@steffahn` `@orlp` and `@Noratrieb` all have full context on this, I'm opening the pull request trying to be helpful. I'm not sure if anything else needs to be done, like documentation I'm not aware of or running any special CIs but if I can do anything else please let me know!
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
Removed dependency on the field-offset crate, alternate approach
This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance.
r? ``@Mark-Simulacrum``
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.
It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
Update minifier version to `0.3.4`
It fixes a bug where a whitespace would get removed in `a [attribute]` (you're not forced to add a tag before an attribute selector).
r? ````@notriddle````
Rollup of 5 pull requests
Successful merges:
- #134679 (Windows: remove readonly files)
- #136213 (Allow Rust to use a number of libc filesystem calls)
- #136530 (Implement `x perf` directly in bootstrap)
- #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull)
- #136659 (Pick the max DWARF version when LTO'ing modules with different versions )
r? `@ghost`
`@rustbot` modify labels: rollup
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 https://github.com/rust-lang/rust/issues/135870#issuecomment-2612470540
Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle
This PR should not be merged until the rustc_codegen_llvm part is merged.
I will also alter it a little based on what get's shaved off from the cg_llvm PR,
and address some of the feedback I received in the other PR (including cleanups).
I am putting it already up to
1) Discuss with `@jieyouxu` if there is more work needed to add tests to this and
2) Pray that there is someone reviewing who can tell me why some of my autodiff invocations get lost.
Re 1: My test require fat-lto. I also modify the compilation pipeline. So if there are any other llvm-ir tests in the same compilation unit then I will likely break them. Luckily there are two groups who currently have the same fat-lto requirement for their GPU code which I have for my autodiff code and both groups have some plans to enable support for thin-lto. Once either that work pans out, I'll copy it over for this feature. I will also work on not changing the optimization pipeline for functions not differentiated, but that will require some thoughts and engineering, so I think it would be good to be able to run the autodiff tests isolated from the rest for now. Can you guide me here please?
For context, here are some of my tests in the samples folder: https://github.com/EnzymeAD/rustbook
Re 2: This is a pretty serious issue, since it effectively prevents publishing libraries making use of autodiff: https://github.com/EnzymeAD/rust/issues/173. For some reason my dummy code persists till the end, so the code which calls autodiff, deletes the dummy, and inserts the code to compute the derivative never gets executed. To me it looks like the rustc_autodiff attribute just get's dropped, but I don't know WHY? Any help would be super appreciated, as rustc queries look a bit voodoo to me.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
r? `@jieyouxu`
[`rustc-rayon v0.5.1`](https://github.com/rust-lang/rustc-rayon/pull/14)
added `indexmap` implementations that will allow `indexmap` to drop its
own "internal-only" implementations.
(This is separate from `indexmap`'s implementation for normal `rayon`.)
- Don't show environment variables. Seeing PATH is almost never useful, and it can be extremely long.
- For .rlibs in the sysroot, replace crate hashes with a `"-*"` string. This will expand to the full crate name when pasted into the shell.
- Move `.rlib` to outside the glob.
- Abbreviate the sysroot path to `<sysroot>` wherever it appears in the arguments.
This also adds an example of the linker output as a run-make test. Currently it only runs on x86_64-unknown-linux-gnu, because each platform has its own linker arguments. So that it's stable across machines, pass BUILD_ROOT as an argument through compiletest through to run-make tests.
- Only use linker-flavor=gnu-cc if we're actually going to compare the output. It doesn't exist on MacOS.
handle global trait bounds defining assoc types
This also fixes the compare-mode for
- tests/ui/coherence/coherent-due-to-fulfill.rs
- tests/ui/codegen/mono-impossible-2.rs
- tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs
- tests/ui/nll/issue-61320-normalize.rs
I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. ecda83b30f/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs (L785)
This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break.
r? `@compiler-errors`
Update the `wasm-component-ld` tool
This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12. This pulls in a fix for the binary adapters that are included with this tool for an issue described in bytecodealliance/wasmtime#10058. Some other dependencies have additionally been updated in the meantime of `wasm-component-ld` but there should otherwise be no major changes.
This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12.
This pulls in a fix for the binary adapters that are included with this
tool for an issue described in bytecodealliance/wasmtime#10058. Some
other dependencies have additionally been updated in the meantime of
`wasm-component-ld` but there should otherwise be no major changes.
