| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is to prove that the frontmatter is preserved.
The choices in tests is intended for showing the different parts of the
proposed Style Guide for frontmatters.
|
|
Improve context of bootstrap errors in CI
Inspired by https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/printing.20test.20suite.20name.20by.20default/with/534920583, this PR attempts to improve the context displayed when a bootstrap invocation fails in CI.
Since https://github.com/rust-lang/rust/pull/145261, we now see the latest started step when a failure occurs. However, we can go further.
1) The first commit prints the actual executed bootstrap invocation command arguments when bootstrap ends. Since CI jobs often run multiple bootstrap commands, this makes it easier to figure out which one of them failed (before it was annoying having to search for that in CI logs). Because bootstrap doesn't really use `Result`s much, and most of them time it ends with the `detail_exit` function, which YOLOs `std::process::exit(...)`, I added the print there.
2) Adds `#[track_caller]` to a few bootstrap Cargo builder functions. This makes the log that we print when a command fails more accurate:
```
2025-08-16T18:18:51.6998201Z Command ... failed ...
2025-08-16T18:18:51.7003653Z Created at: src/bootstrap/src/core/builder/cargo.rs:423:33
2025-08-16T18:18:51.7004032Z Executed at: src/bootstrap/src/core/build_steps/doc.rs:933:26
```
Before, the `cargo.rs:XYZ` location wasn't very useful.
3) Is the most wild thing (I'll revert if you find it too magical). We store the step stack of the currently active `Builder` instance in a global variable, and when bootstrap exits with a failure, we print the stack, to make it easier to find out what was happening when a failure occurred. We could print an actual captured `Backtrace`, but I think that would be too much information in the common case. We now pass `RUST_BACKTRACE=1` on CI, so if bootstrap actually crashes unexpectedly, we would see the stacktrace.
The end of the bootsrap failure log in CI now looks like this now:
```
Bootstrap failed while executing `x build library`
---BOOTSTRAP step stack start---
Assemble { target_compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu, forced_compiler: false } }
Rustc { target: x86_64-unknown-linux-gnu, build_compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, crates: [] }
---BOOTSTRAP step stack end---
```
r? `@jieyouxu`
|
|
Fix uplifting in `Assemble` step
In https://github.com/rust-lang/rust/pull/145310, I removed [this line](https://github.com/rust-lang/rust/pull/145310/files#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L2109), which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (https://github.com/rust-lang/rust/issues/145534). I could swear I tested this in the PR, but somehow I missed it.
Instead of keeping the original returned stage, I made it more explicit by returning the actually used `build_compiler` from the `Rustc` step, and then use that in the `Assemble` step.
The changes to `RustcLink` were needed to fix `ui-fulldeps`, which apparently build a stage3 rustc, because I haven't fixed the test steps yet :sweat_smile:
Hopefully we might be able to remove `RustcLink` if the approach from https://github.com/rust-lang/rust/pull/144252 will work.
Should fix https://github.com/rust-lang/rust/issues/145534.
r? ``@jieyouxu``
|
|
r=lolbinarycat,GuillaumeGomez
rustdoc-search: search backend with partitioned suffix tree
Before:
- https://notriddle.com/windows-docs-rs/doc-old/windows/
- https://doc.rust-lang.org/1.89.0/std/index.html
- https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html
After:
- https://notriddle.com/windows-docs-rs/doc/windows/
- https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html
- https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html
## Summary
Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called [stringdex](https://crates.io/crates/stringdex), that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, *incremental* algorithm.
## Motivation
Fixes https://github.com/rust-lang/rust/issues/131156
While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's.
Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever [place new matches on top of old ones](https://web.dev/articles/cls). It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running.
## Explanation
A longer description of how name search works can be found in stringdex's [HACKING.md](https://gitlab.com/notriddle/stringdex/-/blob/main/HACKING.md) file.
Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match.
## Drawbacks
It's rather complex, and takes up more disk space than the current flat list of strings.
## Rationale and alternatives
Instead of a suffix tree, I could've used a different [approximate matching data structure](https://en.wikipedia.org/wiki/Approximate_string_matching). I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match [oepn](https://doc.rust-lang.org/nightly/std/?search=oepn) like the current system does).
## Prior art
[Sherlodoc](https://github.com/art-w/sherlodoc) is based on a similar concept, but they:
- use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here
- use substring matching for name-based search, [but not fuzzy name matching](https://github.com/art-w/sherlodoc/issues/21)
- actually implement body text search, which is a potential-future feature, but not implemented in this PR
## Future possibilities
### Low-level optimization in stringdex
There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself.
- Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be.
- Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit)
- The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them.
- Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb.
### Improved recall in type-driven search
Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want.
What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise.
For example, a type theoretical improvement would fix [`Iterator<T>, (T -> U) -> Iterator<U>`](https://doc.rust-lang.org/nightly/std/?search=Iterator%3CT%3E%2C%20(T%20-%3E%20U)%20-%3E%20Iterator%3CU%3E) to give [`Iterator::map`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.map), because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one.
## Full-text search
Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching.
Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks:
- You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter.
- Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat.
Neither of these problems are deal-breakers, but they're worth keeping in mind.
|
|
Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std
Before, when bootstrap did a check build of rustc stage N (with a build compiler that was stage N-1), it automatically copied the resulting `.rmeta` artifacts into the sysroot of the stage N-1 build compiler, so that stage N `rustc_private` tools such as `miri` could be compiled using the stage N-1 build compiler. This has a number of issues:
- It was done unconditionally, even if no `rustc_private` tools were actually built.
- If we did a check and a build of the same stage compiler in the same bootstrap invocation, the generated rmeta and rlib files could clash. This is also why you can see that `check::Std` actually doesn't copy the artifacts anymore (which forced us to build std instead of just checking it in a bunch of `Check` steps).
- It was polluting the sysroot of the build compiler. This is especially annoying for the stage 0 compiler, because we are forced to create an artificial sysroot for it, so that we can copy new stuff into it.
- It was very implicit in bootstrap.
Based on suggestions by ```@cuviper``` and ```@bjorn3,``` I tried to change how this behaves. Instead of copying the rmeta artifacts into the sysroot of the build compiler (from where they would be loaded implicitly), they are now stored in a separate transient bootstrap build directory, and they are then explicitly passed *only* when checking `rustc_private` tools using the `-L` flag. The flags are passed out-of-band through our rustc wrapper, to avoid invalidating the build cache. This is the first commit.
The second commit does the same for std. For a few months, we used to build std instead of just checking it when doing a cross-compile check of something that required std, this now fixes it. There is still the previous ordering requirement though, that `check::Std` has to be executed as the last check step, or rather nothing that requires checked std should be executed *after* it, because it will run into rmeta/rlib duplications (https://github.com/rust-lang/rust/blob/4fa90ef7996f891f7f1e126411e5d75afe64accf/src/bootstrap/src/core/builder/mod.rs#L1066). I tried to fix in this PR, but it quickly runs into the fact that building things currently copies *rlib* artifacts into the build compiler sysroot. I want to fix that as one of the next steps. After we get rid of all the copies (or rather, we only do the copies for dist/stage2+ and do not copy anything into the stage0 compiler's sysroot), we could hopefully finally get rid of `stage0-sysroot`.
Based on my local tests, this seems to be working fine. If it works on CI, and we don't run into other issues after merging it, I'd like to do the same also for rlib artifacts generated during `x build`.
r? ```@jieyouxu```
|
|
Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`
This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)).
The new attribute also works on modules, traits and impl items and thus enables usage as the following:
```rust
#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
trait MyTrait {
#[sanitize(address = "off")]
fn unsanitized_default(..) {}
}
#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
r? ```@rcvalle```
|
|
ci: add timeout to windows disk cleanup wait
|
|
|
|
|
|
Update cargo
28 commits in 840b83a10fb0e039a83f4d70ad032892c287570a..71eb84f21aef43c07580c6aed6f806a6299f5042
2025-07-30 13:59:19 +0000 to 2025-08-17 17:18:56 +0000
- update tests to match lint message changes from rust-lang/rust#140794 (rust-lang/cargo#15849)
- chore: downgrade to libc@0.2.174 (rust-lang/cargo#15851)
- Reorder `lto` options in profiles.md (rust-lang/cargo#15841)
- feat(unstable): add -Zbuild-analysis unstable feature (rust-lang/cargo#15845)
- refactor(unstable): group stabilized features (rust-lang/cargo#15846)
- Fixes error while running the cargo clippy --all-targets -- -D warning (rust-lang/cargo#15843)
- Clarify that `cargo doc --no-deps` is cumulative and won’t delete prev (rust-lang/cargo#15800)
- docs: Formatting and cross-linking to build-dir/target-dir docs (rust-lang/cargo#15840)
- Stabilize `build.build-dir` (rust-lang/cargo#15833)
- make resolve features public for cargo-as-a-library (rust-lang/cargo#15835)
- chore(deps): bump slab from 0.4.10 to 0.4.11 (rust-lang/cargo#15832)
- chore: remove x86_64-apple-darwin from CI and tests (rust-lang/cargo#15831)
- chore(deps): update msrv (3 versions) to v1.87 (rust-lang/cargo#15819)
- perf(package): Always reuse the workspace's target-dir (rust-lang/cargo#15783)
- More helpful error for invalid cargo-features = [] (rust-lang/cargo#15781)
- Add initial integration for `--json=timings` behing `-Zsection-timings` (rust-lang/cargo#15780)
- add is_inherited methods to InheritableDependency and InheritableField (rust-lang/cargo#15828)
- chore(deps): update compatible (rust-lang/cargo#15804)
- docs(unstable): Link out to the Plumbing commands effort (rust-lang/cargo#15821)
- chore(deps): update cargo-semver-checks to v0.43.0 (rust-lang/cargo#15825)
- test(build-std): relax the thread name assertion (rust-lang/cargo#15822)
- chore(deps): update msrv (1 version) to v1.89 (rust-lang/cargo#15815)
- Update semver tests for 1.89 (rust-lang/cargo#15816)
- Accessing each build script's `OUT_DIR` and in the correct order (rust-lang/cargo#15776)
- chore: bump to 0.92.0; update changelog (rust-lang/cargo#15807)
- docs: `-Zpackage-workspace` has been stabilized (rust-lang/cargo#15808)
- chore(deps): update rust crate cargo_metadata to 0.21.0 (rust-lang/cargo#15795)
- docs(build-rs): Fix broken intra-doc links (rust-lang/cargo#15810)
|
|
|
|
|
|
|
|
|
|
|
|
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
|
|
Speedup `copy_src_dirs` in bootstrap
I was kinda offended by how slow it was. Just the `copy_src_dirs` part took ~3s locally in the `x dist rustc-src` step. In release mode it was just 1s, but that's kind of cheating (I wonder if we should build bootstrap in release mode on CI though...).
Did some basic optimizations to bring it down to ~1s also in debug mode.
Maybe it's overkill, due to https://github.com/rust-lang/rust/pull/145455. Up to you whether we should merge it or close it :)
r? `````````@jieyouxu`````````
|
|
Add static glibc to the nix dev shell
This fixes `tests/ui/process/nofile-limit.rs` which fails to link on nixos for me without this change.
|
|
Fix outdated doc comment
This updates the documentation comment for `Type::is_doc_subtype_of` to more accurately describe its purpose as a subtyping check, rather than equality
fixes rust-lang/rust#138572
r? ````````````@tgross35````````````
|
|
|
|
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
|
|
Revert "Partially outline code inside the panic! macro".
This reverts https://github.com/rust-lang/rust/pull/115670
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
|
|
|
|
This helps to avoid polluting the sysroot of the build compiler.
|
|
|
|
The target is removed by `copy_link` too, so no need to duplicate the syscall.
|
|
Do not copy files in `copy_src_dirs` in dry run
This reduces the time to run the current 9 dist snapshot tests from ~24s to ~2s on my PC.
r? `@jieyouxu`
|
|
Fix tracing debug representation of steps without arguments in bootstrap
I was wondering why I see `lainSourceTarbal` in tracing logs...
r? `@jieyouxu`
|
|
Remove duplicated tracing span in bootstrap
`trace_cmd` is now called also in the `stream` method, so including it also here was duplicating command spans.
r? `@jieyouxu`
|
|
|
|
|
|
|
|
|
|
this fixes `tests/ui/process/nofile-limit.rs` which fails to link on
nixos for me without this change
|
|
Enhance UI test output handling for runtime errors
When a UI test runs a compiled binary and an error/forbid pattern check fails, the failure message previously only showed compiler output, hiding the executed programs stdout/stderr. This makes it harder to see near-miss or unexpected runtime lines.
Fixed rust-lang/rust#141531
Supersedes rust-lang/rust#141977
|
|
bootstrap: Reduce dependencies
Eliminate the `fd-lock` dependency by using the new native locking in std.
Eliminate the `xattr` dependency by turning off a feature flag in `tar`, since
the tarballs that we extract with bootstrap don't need it.
|
|
Deduplicate -L search paths
For each -L passed to the compiler, we eagerly scan the whole directory. If it has a lot of files, that results in a lot of allocations. So it's needless to do this if some -L paths are actually duplicated (which can happen e.g. in the situation in the linked issue).
This PR both deduplicates the args, and also teaches rustdoc not to pass duplicated args to merged doctests.
Fixes: https://github.com/rust-lang/rust/issues/145375
|
|
r=jieyouxu
Split codegen backend check step into two and don't run it with `x check compiler`
This reduces the amount of work that is done during `x check compiler`. We still check both backends during `x check` by defaut, even if they are not in `rust.codegen-backends`, as just checking them shouldn't require expensive preparations, like building GCC.
r? `@jieyouxu`
|
|
ci: clean windows disk space in background
|
|
Reduce usage of `compiler_for` in bootstrap
While working on refactoring/fixing `dist` steps, I realized that `build.full-bootstrap` does much more than it should, and that it its documentation is wrong. It seems that the main purpose of this option should be to enable/disable stdlib/compiler uplifting (https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Purpose.20of.20.60build.2Efull-bootstrap.60/with/533985624), but currently it also affects staging, or more precisely which compiler will be used to build selected steps, because this option is used in the cursed `compiler_for` function.
I would like to change the option it so that it *only* affects uplifting, and doesn't affect stage selection, which I (partially) did in this PR. I removed the usage of `compiler_for` from the `Std` and `Rustc` steps, and explicitly implemented uplifting, without going through `compiler_for`.
The only remaining usages of `compiler_for` are in dist steps (which I'm currently refactoring, will send a PR later) and test steps (which I will take a look at after dist). After that we can finally remove the function.
I tried to document the case when uplifting was happening during cross-compilation, which was very implicit before. I also did a slight change in the uplifting logic for rustc when cross-compiling. Before, we would attempt to uplift a stage1 rustc, but that is not really a thing when cross-compiling.
r? `@jieyouxu`
|
|
When a UI test runs a compiled binary and an error/forbid pattern
check fails, the failure message previously only showed compiler output,
hiding the executed programs stdout/stderr. This makes it harder to
see near-miss or unexpected runtime lines.
|
|
|
|
|
|
|
|
compiler`
|
|
[rustdoc] Revert "rustdoc search: prefer stable items in search results"
Reverts https://github.com/rust-lang/rust/pull/141658 and reverts https://github.com/rust-lang/rust/pull/145349.
Reopens https://github.com/rust-lang/rust/issues/138067.
r? ```@fmease```
|
|
r=alexcrichton
fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute
Resolves rust-lang/rust#140174
r? ```@alexcrichton```
try-job: `test-various*`
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 18 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-svg v0.1.9 -> v0.1.10
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating camino v1.1.10 -> v1.1.11
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating cxx v1.0.161 -> v1.0.166
Updating cxx-build v1.0.161 -> v1.0.166
Updating cxxbridge-cmd v1.0.161 -> v1.0.166
Updating cxxbridge-flags v1.0.161 -> v1.0.166
Updating cxxbridge-macro v1.0.161 -> v1.0.166
Updating derive-where v1.5.0 -> v1.6.0
Updating hashbrown v0.15.4 -> v0.15.5
Updating indenter v0.3.3 -> v0.3.4
Updating rustversion v1.0.21 -> v1.0.22
Updating scratch v1.0.8 -> v1.0.9
Updating zerovec v0.11.2 -> v0.11.4
note: pass `--verbose` to see 36 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating hashbrown v0.15.4 -> v0.15.5
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 10 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating cc v1.2.31 -> v1.2.32
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating clap_complete v4.5.55 -> v4.5.56
Updating hashbrown v0.15.4 -> v0.15.5
Updating rustversion v1.0.21 -> v1.0.22
Updating zerovec v0.11.2 -> v0.11.4
```
|
|
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
|
|
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
|
