| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=oli-obk
Async drop fix for async_drop_in_place<T> layout for unspecified T
Fix for https://github.com/rust-lang/rust/issues/140423.
Layout of `async_drop_in_place<T>::{closure}` is calculated for unspecified T from dataflow_const_prop `try_make_constant`.
`@oli-obk,` do you think, it may be a better solution to add check like `if !args[0].is_fully_specialized() { return None; }` in `fn async_drop_coroutine_layout`?
And could you, pls, recommend, how to implement `is_fully_specialized()` in a most simple way?
|
|
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
|
|
Rollup of 7 pull requests
Successful merges:
- #140792 (Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations)
- #140795 (Prefer to suggest stable candidates rather than unstable ones)
- #140865 (Make t letter looks like lowercase rather than uppercase)
- #140878 (Two expand-related cleanups)
- #140882 (Split duration_constructors to get non-controversial constructors out)
- #140886 (Update deps of bootstrap for Cygwin)
- #140903 (test intrinsic fallback bodies with Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
test intrinsic fallback bodies with Miri
`@Urgau` noted in https://github.com/rust-lang/rust/pull/140792 that fallback bodies our backends don't use are untested... which is correct, and it is a problem. So this adds a testing-only flag to Miri to force the use of fallback bodies, and adds a run of the Miri test suite with that flag to CI. This should not take much more than a minute so I hope it's fine? Let's see how long it actually takes.
While at it, I made that test run also enable MIR optimizations. Miri's CI has a run with that, and it has caught mir-opt bugs in the past -- this way we'd see the CI failure earlier.
r? `@scottmcm`
|
|
Update deps of bootstrap for Cygwin
This PR just runs
```
cargo update fd-lock xattr libc errno
```
It reduces dependency on `rustix 0.38.40` and updates `libc` & `errno`. Now it compiles successfully on Cygwin:)
|
|
Split duration_constructors to get non-controversial constructors out
This implements #140881
|
|
Two expand-related cleanups
Minor improvements I found while looking at this code. Best reviewed one commit at a time.
r? `@BoxyUwU`
|
|
Make t letter looks like lowercase rather than uppercase
randomly noticed that, took opportunity to fix :D
it was looks like "RusT" now fixed to "Rust"
r? `@jieyouxu`
before
<img src="https://github.com/user-attachments/assets/1ff19891-2e7b-4633-897d-2b2635aff9c6" width="65%" />
now
<img src="https://github.com/user-attachments/assets/d577a2af-6755-411b-8050-2556f0f12e75" width="65%" />
|
|
r=petrochenkov
Prefer to suggest stable candidates rather than unstable ones
Fixes #140240
The logic is to replace unstable suggestions if we meet a new stable one, and do nothing if any other situation. In old logic, we just use the first candidate we meet as the suggestion for the same items.
E.g., `std::range::legacy::Range` vs `std::ops::Range`, `legacy` in the former is unstable, we prefer to suggest use the latter.
|
|
r=scottmcm,traviscross,tgross35
Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations
This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations.
This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them.
Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`.
r? `@tgross35`
try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2
[^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
|
|
|
|
Fix download of GCC from CI on non-nightly channels
Fixes the download failure on beta (https://github.com/rust-lang/rust/pull/140897#issuecomment-2868974932).
r? `@onur-ozkan`
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #129334 (Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]`)
- #139562 (rustdoc: add a handle that makes sidebar resizing more obvious)
- #140151 (remove intrinsics::drop_in_place)
- #140660 (remove 'unordered' atomic intrinsics)
- #140783 (Update documentation of OnceLock::get_or_init.)
- #140789 (Update hermit-abi to 0.5.1)
- #140879 (1.87.0 release notes: remove nonsensical `~` operator)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
1.87.0 release notes: remove nonsensical `~` operator
There is no `~` unary prefix operator, and it definitely shouldn't be in the release notes for a feature whose introducing PR doesn't test for it (because it doesn't exist). Also fix an unnecessary `}` on the same line.
r? ``@pietroalbini``
|
|
Update hermit-abi to 0.5.1
This updates hermit-abi to version 0.5.1, bringing the [recent `AF_*`](https://github.com/rust-lang/libc/pull/4344) changes to std.
|
|
Update documentation of OnceLock::get_or_init.
Explicitly point out that if the function panics the init function might be called multiple times.
|
|
remove 'unordered' atomic intrinsics
As their doc comment already indicates, these operations do not currently have a place in our memory model. The intrinsics were introduced to support a hack in compiler-builtins, but that hack recently got removed (see https://github.com/rust-lang/compiler-builtins/issues/788).
|
|
r=Mark-Simulacrum
remove intrinsics::drop_in_place
This was only ever accidentally stable, and has been marked as deprecated since Rust 1.52, released almost 4 years ago. We've removed the old serialization `derive`s, maybe we can remove this one as well?
As suggested by ``@jhpratt,`` let's see what crater says for this one.
|
|
rustdoc: add a handle that makes sidebar resizing more obvious
This aims to make the resizable sidebars more obvious
Preview: <https://notriddle.com/rustdoc-html-demo-12/sidebar-resize-handle/std/index.html>
This change is based on some discussion on [lolbinarycat's idea], but with a more "traditional" design. Specifically, while very few systems use exactly this design, most of them use [a skeumorph](https://ux.stackexchange.com/questions/80463/what-do-the-3-close-horizontal-bars-not-hamburger-menu-represent-and-what-is-t/80591#80591) of a grip texture:
- This design is similar to the one used in the Rust Playground, and almost identical to UX StackExchange:
<details><img src="https://github.com/user-attachments/assets/39a6bb69-4895-4fd0-87da-b87913bc7309"></details>
<details><img src="https://github.com/user-attachments/assets/a41942e1-651b-410b-b855-2aafe8fe54f4"></details>
- In Jira, resizable sidebars have a stack of four dots, but only in one row.
<details><img src="https://github.com/user-attachments/assets/13047998-02bf-47e6-b796-16f393f870b0"></details>
- In The GIMP, resizable sidebars have a stack of three dots.
<details><img src="https://github.com/user-attachments/assets/138f5c21-3069-4bbe-b306-0bb9a4bf0318"></details>
- In [old Windows], "panes" are defined to have the same border style as a window, which has a raised appearance. To evoke this, the PR adds a lightweight "shadow" border, darker than the sidebar itself
<details><img src="https://github.com/user-attachments/assets/301da4b8-6c48-4131-b741-1689af84670a"></details>
- In [NeXT], a drag point usually had an innie, whether the line in a slider or the circle in a scroller; I can also hide and show the favorites bar in Workspace by dragging on a circular "grip spot"
<details><img src="https://github.com/user-attachments/assets/b13c2d30-a3a8-4672-90fa-58c1fdf19f42"></details>
- In [old Mac], drag handles for things usually had a "grip track" of parallel lines.
<details><img src="https://github.com/user-attachments/assets/1fbecc67-ffbc-4ed6-a8c5-a9ff085638db"></details>
*This design is far closer to old Mac than anything else*, though they've put it in the bottom corner instead of the middle.
- [OSX] kept that, but the "Source List" part of the Finder still had the circle grip for a time the same way Workspace did (resulting in an odd mishmash, if you compare the source list sidebar with the other grip tracks embedded in the scrollbars).
<details><img src="https://github.com/user-attachments/assets/551b8f9d-2dd8-4291-917f-dc88741a2b97"></details>
[lolbinarycat's idea]: https://github.com/rust-lang/rust/pull/139420
[old Windows]: https://archive.org/details/windowsinterface00micr/page/n9/mode/2up
[old Mac]: https://archive.org/details/apple-hig/1996_Human_Interface_Guidelines_for_Mac_OS_8_%28WWDC_Release%29/page/16/mode/2up
[NeXT]: https://archive.org/details/apple-hig/1993%20NeXTSTEP%20User%20Interface%20Guidelines%20-%20Release%203/page/145/mode/2up
[OSX]: https://dn721903.ca.archive.org/0/items/apple-hig/MacOSX_HIG_2005_09_08.pdf#page=267
|
|
Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]`
`DerefMut` is instantly stable, as a trait impl. That means this needs an FCP.
``@rustbot`` label +needs-fcp
https://github.com/rust-lang/libs-team/issues/429
|
|
Merge typeck loop with static/const item eval loop
r? `@ghost`
Let's try a small one first. Doing this in general has some bad cache coherence issues because the query caches are laid out in `Vec<QueryResult>` lists per query where each index refers to a `DefId` in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
|
|
Make the assertion in `Ident::new` debug-only.
This fixes a perf regression introduced in #140252.
r? `@oli-obk`
|
|
|
|
Update `backtrace` in Cargo.lock
Ran `cargo update -p backtrace`. This is needed to forward port the rust-gpu compiler backend.
Subsumes https://github.com/rust-lang/rust/pull/140631. Was supposed to be fixed by https://github.com/rust-lang/rust/pull/140353, but there were test failures and the backtrace update was backed out.
|
|
Update cargo
25 commits in 7918c7eb59614c39f1c4e27e99d557720976bdd7..056f5f4f3c100cb36b5e9aed2d20b9ea70aae295
2025-04-27 09:44:23 +0000 to 2025-05-09 14:54:18 +0000
- Revert "doc: Mention `XDG_DATA_HOME`" (rust-lang/cargo#15512)
- docs: update version notice for deprecation removal (rust-lang/cargo#15511)
- doc: Update instructions on using native-completions (rust-lang/cargo#15480)
- feat(network): use Retry-After header for HTTP 429 responses (rust-lang/cargo#15463)
- CI: Require schema job to pass (rust-lang/cargo#15504)
- chore(config): migrate renovate config (rust-lang/cargo#15501)
- Make cargo script ignore workspaces (rust-lang/cargo#15496)
- fix(rustc): Don't panic on unknown bins (rust-lang/cargo#15497)
- test: Remove unused nightly requirements (rust-lang/cargo#15498)
- Add support for `-Zembed-metadata` (rust-lang/cargo#15378)
- Fix tracking issue template link (rust-lang/cargo#15494)
- Refactor artifact deps in FeatureResolver::deps (rust-lang/cargo#15492)
- Improved error message for versions prefixed with `v` (rust-lang/cargo#15484)
- chore: fix some typos in comment (rust-lang/cargo#15485)
- fix: default to all targets when using `--edition` and ` --edition-idioms` in cargo fix (rust-lang/cargo#15192)
- Update fingerprint footnote (rust-lang/cargo#15478)
- feat(add): suggest similarly named features (rust-lang/cargo#15438)
- In package-workspace, keep dev-dependencies if they have a version (rust-lang/cargo#15470)
- docs: fix a typo in DependencyUI (rust-lang/cargo#15472)
- fix grammar, and remove confusing example (rust-lang/cargo#15457)
- Added tracing spans for rustc invocations (rust-lang/cargo#15464)
- Trivial tweaks to 'target_short_hash' (rust-lang/cargo#15461)
- chore(deps): update msrv (3 versions) to v1.84 (rust-lang/cargo#15456)
- feat(add/install): check if given crate argument would be valid with inserted @ symbol (rust-lang/cargo#15441)
- chang 1 tries to 1 try (rust-lang/cargo#15328)
r? ghost
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #139863 (rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg`)
- #140815 (also export metrics from librustdoc)
- #140819 (Add regression test for 125877)
- #140843 (Fix `broken-pipe-no-ice` run-make test for rpath-less builds)
- #140848 (Improved error message for top-level or-patterns)
- #140852 (Update the edition guide for let chains)
- #140864 (Last minute relnotes fix)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This fixes a perf regression introduced in #140252.
|
|
|
|
There is no `~` unary prefix operator, and it definitely shouldn't be in the release notes for a feature whose introducing PR doesn't test for it (because it doesn't exist).
|
|
It's a "utility trait to reduce boilerplate" implemented for `P` and
`AstNodeWrapper`, but removing it gives a net reduction of twenty lines
of code. It's also simpler to just implement
`HasNodeId`/`HasAttrs`/`HasTokens` directly on types instead of via
`AstDeref`.
(I decided to make this change when doing some related refactoring and
the error messages involving `AstDeref` and `HasAttrs` were hard to
understand; removing it helped a lot.)
|
|
|
|
|
|
Last minute relnotes fix
This PR applies most of the suggestions in https://github.com/rust-lang/rust/pull/140802#discussion_r2080675967 (except for `as_flattened_mut`, which is indeed a const stabilization this cycle), and replaces all links from nightly to stable.
r? `@BoxyUwU`
|
|
Update the edition guide for let chains
Pull https://github.com/rust-lang/edition-guide/pull/337 into the rustc tree.
|
|
Improved error message for top-level or-patterns
I was confused by "top-level or-patterns are not allowed in `let` bindings" error, because it sounded like or-patterns were completely unsupported.
This error has an auto-fix suggestion that shows otherwise, but the auto-fix isn't always visible in IDEs.
I've changed the wording to be consistent with "`Fn` bounds require arguments in parentheses", and it doesn't sound like a dead-end any more.
|
|
Fix `broken-pipe-no-ice` run-make test for rpath-less builds
The `broken-pipe-no-ice` run-make test currently fails on rpath-less builds, because host compiler runtime libs are not configured for raw std command usages.
This PR is an alternative approach to #140744. However, instead of duplicating `run_make_support::util::set_host_compiler_dylib_path` logic, we instead support "ejecting" the "configured" underlying std `Command` from `bare_rustc()` and `rustdoc()`, where host compiler runtime libs are already set.
cc `@jchecahi`
r? `@Kobzol`
|
|
Add regression test for 125877
close: #125877
https://github.com/rust-lang/rust/issues/125877#issuecomment-2143704586 has been resolved https://github.com/rust-lang/rust/pull/128171
|
|
also export metrics from librustdoc
Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331)
The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published.
This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled.
Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
|
|
r=GuillaumeGomez
rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg`
Tracking issue: https://github.com/rust-lang/rust/issues/134172.
Context: https://github.com/rust-lang/rust/pull/137096#issuecomment-2776318800
Yeets the ad hoc shell-like lexer for 'nested' program arguments.
No FCP necessary since the flag is unstable.
I've chosen to replace `compilation` with `build` because it's shorter (you now need to pass it multiple times in order to pass many arguments to the doctest compiler, so it matters a bit) and since I prefer it esthetically.
**Issue**: Even though we don't process the argument passed to `--doctest-build-arg`, we end up passing it via an argument file (`rustc `@argfile`)` which delimits arguments by line break (LF or CRLF, [via](https://doc.rust-lang.org/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path)) meaning ultimately the arguments still get split which is unfortunate. Still, I think this change is an improvement over the status quo.
I'll update the tracking issue if/once this PR merges. I'll also add the (CR)LF issue to 'unresolved question'.
r? GuillaumeGomez
r? notriddle
|
