| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
rustdoc-search: single result for items with multiple paths
Part of #15723
Preview: https://notriddle.com/rustdoc-html-demo-9/reexport-dup/std/index.html?search=hashmap
This change uses the same "exact" paths as trait implementors and type alias inlining to track items with multiple reachable paths. This way, if you search for `vec`, you get only the `std` exports of it, and not the one from `alloc`.
It still includes all the items in the search index so that you can search for them by all available paths. For example, try `core::option` and `std::option`, and notice that the results page doesn't show duplicates, but still shows all the items in their respective crates.
|
|
r=oli-obk,onur-ozkan
At debuginfo=0, don't inline debuginfo when inlining
See https://github.com/rust-lang/rust/pull/123949#issuecomment-2060493285 for info.
|
|
|
|
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
|
|
|
|
|
|
|
|
Remove libc from more tests
The goal here is to trim down the number of tests that depend on libc from the sysroot to make https://github.com/rust-lang/rust/pull/123938 more plausible.
This PR is a few simple cases that I missed in https://github.com/rust-lang/rust/pull/123943.
|
|
|
|
r=GuillaumeGomez,ChrisDenton,wesleywiser
Add support for Arm64EC to the Standard Library
Adds the final pieces so that the standard library can be built for arm64ec-pc-windows-msvc (initially added in #119199)
* Bumps `windows-sys` to 0.56.0, which adds support for Arm64EC.
* Correctly set the `isEC` parameter for LLVM's `writeArchive` function.
* Add `#![feature(asm_experimental_arch)]` to library crates where Arm64EC inline assembly is used, as it is currently unstable.
|
|
Simplify `static_assert_size`s.
We want to run them on all 64-bit platforms.
r? `@ghost`
|
|
Rollup of 5 pull requests
Successful merges:
- #124041 (Fix copy path button)
- #124047 (Match ergonomics 2024: miscellaneous code cleanups)
- #124064 (Move confusing comment about otherwise blocks in `lower_match_tree`)
- #124090 (llvm: update riscv target feature to match LLVM 19)
- #124100 (fix: make `str::from_raw_parts_mut` `mut`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix: make `str::from_raw_parts_mut` `mut`
`str::from_raw_parts_mut` wasn't actually `mut`
#119206
|
|
llvm: update riscv target feature to match LLVM 19
In llvm/llvm-project@9067070d91e9d8cdd8509ffa56a076f08a3d7281 they ended up largely reverting
llvm/llvm-project@e81796671890b59c110f8e41adc7ca26f8484d20. This means the change we did in
rust-lang/rust@b378059e6b2573c5356423fa31d184a89a3b6029 is now only corrct for LLVM 18...so we have to adjust again.
``@rustbot`` label: +llvm-main
|
|
Move confusing comment about otherwise blocks in `lower_match_tree`
This comment was historically inside a block guarded by `if let Some(otherwise_block) = otherwise`.
When #120978 made the “otherwise block” non-optional, it also flattened that region of code. Doing so left this comment awkwardly stranded above an unrelated line of code, without its original context.
We can restore that context by moving it above the declaration of `otherwise`.
r? ``@Nadrieril``
|
|
Match ergonomics 2024: miscellaneous code cleanups
- Store `ByRef` instead of `BindingAnnotation` in `PatInfo`
- Rename `BindingAnnotation` to `BindingMode`
r? ``@Nadrieril``
cc #123076
``@rustbot`` label A-patterns
|
|
Fix copy path button
Currently, on all nightly docs, clicking on the "copy path" button triggers a JS error. It's because changes in https://github.com/rust-lang/rust/pull/123706 forgot to update the JS (it contained an image before but not anymore).
I had to make some small changes in the CSS to fix the display when the button was clicked as well.
r? ``@notriddle``
|
|
We want to run them on all 64-bit platforms.
|
|
r=jieyouxu
crashes: add even more tests?!?
adds more tests that were not already added with https://github.com/rust-lang/rust/pull/124038 from the past 10 months or so.
Need a couple more passes through the tracker to filter out more missing ice /fixed tests but we're slowly getting there.
|
|
|
|
r=RalfJung
Delay interning errors to after validation
fixes https://github.com/rust-lang/rust/issues/122398
fixes #122548
This improves diagnostics since validation errors are usually more helpful compared with interning errors that just make broad statements about the entire constant
r? `@RalfJung`
|
|
Update LLVM to 1deeee3
Fixes #123772.
Diff: https://github.com/rust-lang/llvm-project/compare/af8f9eb61a2ad4ee1f2d3f46d157b93a47c6a4bf...5399a24c66cb6164cf32280e7d300488c90d5765
Diff (From 18.1.2): https://github.com/rust-lang/llvm-project/compare/0af6c732ec6ca189cd7725e4a7d4290793046e83...5399a24c66cb6164cf32280e7d300488c90d5765
r? `@cuviper`
|
|
|
|
Update how WASI toolchains are used in CI and bootstrap
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
|
|
In llvm/llvm-project@9067070d91e9d8cdd8509ffa56a076f08a3d7281 they ended
up largely reverting
llvm/llvm-project@e81796671890b59c110f8e41adc7ca26f8484d20. This means
the change we did in
rust-lang/rust@b378059e6b2573c5356423fa31d184a89a3b6029 is now only
corrct for LLVM 18...so we have to adjust again.
@rustbot label: +llvm-main
|
|
Codegen ZSTs without an allocation
This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.
This regressed in #67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since #63635.
|
|
Rollup of 9 pull requests
Successful merges:
- #116957 (meta: notify #t-rustdoc Zulip stream on backport nominations)
- #122201 (Document overrides of `clone_from()` in core/std)
- #122723 (Use same file permissions for ar_archive_writer as the LLVM archive writer)
- #124030 (interpret: pass MemoryKind to adjust_alloc_base_pointer)
- #124037 (Don't ascend into parent bodies when collecting stmts for possible return suggestion)
- #124049 (Stabilize `const_io_structs`)
- #124062 (Add another expression to weird-exprs.rs)
- #124066 (Don't error on subtyping of equal types)
- #124073 (Remove libc from rust_get_test_int uses)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove libc from rust_get_test_int uses
`rust_test_helpers.c` has a few unfortunate signatures which have made some of our UI tests _technically_ need the `libc` crate. This is my attempt to evict the need of `libc` for `rust_get_test_int`.
I've deleted `tests/ui/abi/foreign/foreign-no-abi.rs` because the test was originally written to check that `native mod` will compile without an ABI specifier. `native mod` was removed years before 1.0 and the test hasn't checked for anything for a long time.
|
|
Don't error on subtyping of equal types
fixes https://github.com/rust-lang/rust/issues/124054 🤦
fixes #124075
fixes https://github.com/rust-lang/rust/issues/124079
r? `@compiler-errors`
|
|
Add another expression to weird-exprs.rs
I'm almost feeling bad for this but I decided I don't.
Feel free to close if you don't approve.
|
|
Stabilize `const_io_structs`
This PR stabilizes `const_io_structs`.
Tracking issue: https://github.com/rust-lang/rust/issues/78812.
Implementation PR: https://github.com/rust-lang/rust/pull/78811.
FCPs already completed in the tracking issue.
Closes https://github.com/rust-lang/rust/issues/78812.
```@rustbot``` label: +T-libs-api
r? libs-api
|
|
Don't ascend into parent bodies when collecting stmts for possible return suggestion
Fixes #124022
|
|
interpret: pass MemoryKind to adjust_alloc_base_pointer
Another puzzle piece for https://github.com/rust-lang/miri/pull/3475.
The 2nd commit renames base_pointer -> root_pointer; that's how Tree Borrows already calls them and I think the term is more clear than "base pointer". In particular, this distinguishes it from "base address", since a root pointer can point anywhere into an allocation, not just its base address.
https://github.com/rust-lang/rust/pull/124018 has been rolled up already so I couldn't add it there any more.
r? ```@oli-obk```
|
|
Use same file permissions for ar_archive_writer as the LLVM archive writer
This is required to switch to ar_archive_writer in the future without regressions. In addition to this PR support for reading thin archives needs to be added (https://github.com/rust-lang/rust/issues/107407) to fix all known regressions.
Fixes https://github.com/rust-lang/rust/issues/107495
|
|
Document overrides of `clone_from()` in core/std
As mentioned in https://github.com/rust-lang/rust/pull/96979#discussion_r1379502413
Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source".
I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that.
Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.
|
|
fmease:meta-notify-rustdoc-zulip-on-backport-nominations, r=GuillaumeGomez
meta: notify #t-rustdoc Zulip stream on backport nominations
In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward ([Zulip announcement](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/T-rustdoc.20backports/near/374828518)). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings).
Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip.
This PR attempts to partially automate this process. ~~Sadly, `triagebot` is not quite as flexible has I've hoped. Blocked on `triagebot` improvements (see the `FIXME`s in this PR).~~ (Fixed in rust-lang/triagebot#1791).
r? GuillaumeGomez
|
|
|
|
|
|
Silence some follow-up errors on trait impls in case the trait has conflicting or otherwise incoherent impls
fixes #123292
Also removes a bunch of extra diagnostics that were introduced in https://github.com/rust-lang/rust/pull/121154 and https://github.com/rust-lang/rust/pull/120558
|
|
|
|
|
|
|
|
|
|
static libraries with ar_archive_writer
Fixes #107495
|
|
|
|
|
|
|
