| Age | Commit message (Collapse) | Author | Lines |
|---|
|
chore: move more ui tests
r? `@jieyouxu`
|
|
|
|
the size of `AsyncStruct`'s destructor depends on whether the configured
panic strategy is 'unwind' or 'abort' so factor that into the test using
conditional compilation
fixes rust-lang/rust#140939
|
|
add regression test for 140207
Assembly test for #140207
|
|
Remove mono item collection strategy override from -Zprint-mono-items
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
|
|
Rollup of 3 pull requests
Successful merges:
- #140397 (Add T-compiler backports Zulip notifications)
- #140851 (Warn when `#[export_name]` is used with generic functions)
- #140862 (Enable non-leaf Frame Pointers for Arm64EC Windows)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
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?
|
|
Enable non-leaf Frame Pointers for Arm64EC Windows
This was enabled for native Arm64 via #140828
r? `@workingjubilee`
|
|
Warn when `#[export_name]` is used with generic functions
Fixes #140742
|
|
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`
|
|
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.
|
|
|
|
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
|
|
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
|
|
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.
|
|
|
|
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
|
|
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
|
|
This change is based on some discussion on [lolbinarycat's idea],
but with a more "traditional" design. Specifically, this is the
closest thing I could find to a consensus across many systems I
looked at for inspiration:
- In Jira, resizable sidebars have a stack of four dots.
- In The GIMP, resizable sidebars have a stack of three dots.
- In [old Windows], "panes" are defined to have the same border
style as a window, which has a raised appearance.
- 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"
- In [old Mac], drag handles for things usually had a "grip track"
of parallel lines.
- [OSX] kept that, but the "Source List" part of the Finder still had
the circle grip for a time the same way Workspace did
[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
|
|
|
|
|
|
|
|
|
|
|
|
Bump version number to 1.89.0
Part of the release process. This PR must not be rolled up.
Closes #129461.
r? `@ghost`
|
|
Where host compiler runtime libs are properly configured, instead of raw
`RUSTC`/`RUSTDOC` commands.
Co-authored-by: Jesus Checa Hidalgo <jchecahi@redhat.com>
|
|
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
|
|
Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu"
This reverts commit 26f75a65d70773e4520634b9f6599ddf08c499e6, reversing
changes made to 2572e0e8c9d5d671eccb1d5791e55c929c4720f4.
Imports are modified to fix merge conflicts and remove unused ones.
|
|
add signed ints to unn- transmutes to ensure feature parity
i forgot a few cases https://github.com/rust-lang/rust-clippy/pull/14703/#pullrequestreview-2824194994
adds
- char -> i32
- i32 -> char
- float -> size ()
- size -> float
- i32 -> float
``@rustbot`` label L-unnecessary_transmutes
|
|
Use span before macro expansion in lint for-loops-over-falibles
Fixes #140747
I think there are going to be a lot of cases where macros are expanded in the compiler resulting in span offsets, and I'd like to know how that's typically handled. Does it have to be handled specially every time?
|
|
|
|
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes #138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
|
|
Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux
Follow-up of #140706.
r? `@jieyouxu`
|
|
Improve `-Zremap-path-scope` tests with dependency
This PR greatly improves our coverage of `-Zremap-path-scope` for diagnostic paths and macros with dependencies.
r? `@jieyouxu` (since we talked about it)
try-job: x86_64-msvc-1
|
|
Structurally normalize in range pattern checking in HIR typeck
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/200
r? lcnr
|
|
Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided
Since #136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given:
```rust
trait Trait {
type Assoc where Self: Sized;
}
```
After #136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing.
After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.
We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.
Fixes #140645
r? lcnr
|
|
|
|
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
[arm64] Pointer auth test should link with C static library statically
While trying to get the aarch64-msvc build working correctly (#140136), the `pointer-auth-link-with-c` test was failing.
The pointer auth test builds its C library statically:
https://github.com/rust-lang/rust/blob/3ef8e64ce9f72ee8d600d55bc43b36eed069b252/tests/run-make/pointer-auth-link-with-c/rmake.rs#L15
However, the Rust code did not indicate the link kind, so it defaulted to dynamic which then fails on Windows.
|
