| Age | Commit message (Collapse) | Author | Lines |
|---|
|
core/slice: Mark some `split_off` variants unstably const
Tracking issue: #138539
Add feature gate `#![feature(const_split_off_first_last)]`
Mark `split_off_first`, `split_off_first_mut`, `split_off_last`, and `split_off_last_mut` slice methods unstably const
|
|
mir_build: consider privacy when checking for irrefutable patterns
This PR fixes #137999.
Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run.
I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
|
|
Implement default methods for `io::Empty` and `io::Sink`
Implements default methods of `io::Read`, `io::BufRead`, and `io::Write` for `io::Empty` and `io::Sink`. These implementations are equivalent to the defaults, except in doing less unnecessary work.
`Read::read_to_string` and `BufRead::read_line` both have a redundant call to `str::from_utf8` which can't be inlined from `core` and `Write::write_all_vectored` has slicing logic which can't be simplified (See on [Compiler Explorer](https://rust.godbolt.org/z/KK6xcrWr4)). The rest are optimized to the minimal with `-C opt-level=3`, but this PR gives that benefit to unoptimized builds.
This includes an implementation of `Write::write_fmt` which just ignores the `fmt::Arguments<'_>`. This could be problematic whenever a user formatting impl is impure, but the docs do not guarantee that the args will be expanded.
Tracked in https://github.com/rust-lang/rust/issues/136756.
r? `@m-ou-se`
|
|
`MaybeUninit` inherent slice methods part 2
These were moved out of #129259 since they require additional libs-api approval. Tracking issue: #117428.
New API surface:
```rust
impl<T> [MaybeUninit<T>] {
// replacing fill; renamed to avoid conflict
pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone;
// replacing fill_with; renamed to avoid conflict
pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T;
// renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods
pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>;
}
```
Relevant motivation for these methods; see #129259 for earlier methods' motiviations.
* I chose `write_filled` since `filled` is being used as an object here, whereas it's being used as an action in `fill`.
* I chose `write_with` instead of `write_filled_with` since it's shorter and still matches well.
* I chose `write_iter` because it feels completely different from the fill methods, and still has the intent clear.
In all of the methods, it felt appropriate to ensure that they contained `write` to clarify that they are effectively just special ways of doing `MaybeUninit::write` for each element of a slice.
Tracking issue: https://github.com/rust-lang/rust/issues/117428
r? libs-api
|
|
Rollup of 10 pull requests
Successful merges:
- #136177 (clarify BufRead::{fill_buf, consume} docs)
- #138654 (Remove the regex dependency from coretests)
- #138655 (rustc-dev-guide sync)
- #138656 (Remove double nesting in post-merge workflow)
- #138658 (CI: mirror alpine and centos images to ghcr)
- #138659 (coverage: Don't store a body span in `FunctionCoverageInfo`)
- #138661 (Revert: Add *_value methods to proc_macro lib)
- #138670 (Remove existing AFIDT implementation)
- #138674 (Various codegen_llvm cleanups)
- #138684 (use then in docs for `fuse` to enhance readability)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rollup of 7 pull requests
Successful merges:
- #136320 (exit: document interaction with C)
- #138080 (Leave a breadcrumb towards bootstrap config documentation in `bootstrap.toml`)
- #138301 (Implement `read_buf` for Hermit)
- #138569 (rustdoc-json: Add tests for `#[repr(...)]`)
- #138635 (Extract `for_each_immediate_subpat` from THIR pattern visitors)
- #138642 (Unvacation myself)
- #138644 (Add `#[cfg(test)]` for Transition in dfa in `rustc_transmute`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
use then in docs for `fuse` to enhance readability
use the more-idiomatic `then_some` rather than an `if { some } else { none }` for `fused` docs
|
|
Various codegen_llvm cleanups
Mostly just adding safe wrappers and deduplicating code
|
|
Remove existing AFIDT implementation
This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented.
r? oli-obk
Fixes #136286
Fixes #137706
Fixes #137895
Tracking:
* #133119
|
|
Revert: Add *_value methods to proc_macro lib
This reverts https://github.com/rust-lang/rust/pull/136355. That PR caused unexpected breakage:
- the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others
- rustc_lexer can no longer be published to crates.io, which impacts RA
See https://github.com/rust-lang/rust/issues/138647 for context.
Cc `@GuillaumeGomez` `@Amanieu`
|
|
coverage: Don't store a body span in `FunctionCoverageInfo`
We aren't using this body span for anything truly essential, and having it around will be awkward when we eventually start to support expansion regions, since they aren't necessarily within the main body.
|
|
CI: mirror alpine and centos images to ghcr
|
|
Remove double nesting in post-merge workflow
See [this](https://github.com/rust-lang/rust/pull/138630#issuecomment-2732224491) :)
Can be tested with:
```bash
#!/bin/bash
PARENT_COMMIT=493c38ba371929579fe136df26eccd9516347c7a
SHA=259fdb521200c9abba547302fc2c826479ef26b2
printf "<details>\n<summary>What is this?</summary>\n" >> output.log
printf "This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.\n" >> output.log
printf "</details>\n\n" >> output.log
cargo run --release post-merge-report ${PARENT_COMMIT} ${SHA} >> output.log
```
I think that it's better to leave the notice in CI, to avoid generating it in citool, which can also be executed locally.
r? `@marcoieni`
|
|
rustc-dev-guide sync
r? `@jieyouxu`
|
|
Remove the regex dependency from coretests
It is only used by a single test, yet would take up unnecessary space once stdlib deps get vendored.
|
|
clarify BufRead::{fill_buf, consume} docs
Fixes #85394
|
|
Temporarily disable Fuchsia test job to unblock queue
See <https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259> for efforts to fix the test job.
This PR temporarily disables the Fuchsia test job to unblock the queue, so that neither the Fuchsia maintainers nor T-infra maintainers should feel pressured to fix the job ASAP.
Please feel free to re-enable once the test job is fixed.
FYI `@erickt` since you or other Fuchsia maintainers will need to revert this change to merge Fuchsia test job fixes in the future.
r? infra-ci
|
|
See
<https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259>
for efforts to fix the test job.
|
|
|
|
|
|
|
|
|
|
GuillaumeGomez:proc-macro_add_value_retrieval_methods, r=Amanieu"
This reverts commit 08dfbf49e30d917c89e49eb14cb3f1e8b8a1c9ef, reversing
changes made to 10bcdad7df0de3cfb95c7bdb7b16908e73cafc09.
|
|
|
|
Given that we now only enlarge empty spans to "{" or "}", there shouldn't be
any danger of enlarging beyond a function body.
|
|
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
It is only used by a single test, yet would take up unnecessary space
once stdlib deps get vendored.
|
|
|
|
Add `#[cfg(test)]` for Transition in dfa in `rustc_transmute`
`Transition` is only used in the `Transitions::insert` in test after #137776
Detected by #128637
|
|
Unvacation myself
Feeling better now.
r? ghost
|
|
Extract `for_each_immediate_subpat` from THIR pattern visitors
This is extracted from some larger changes I've been working on, trying to introduce a “THIR pattern id” to refer to THIR pattern nodes without a direct reference.
The future of those changes is somewhat uncertain, due to some [proposed changes involving upvar inference](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/upvar.20inference.20on.20THIR.3F). So I'm taking my preparatory changes that make sense on their own, and extracting them into one or more independent PRs.
---
This particular patch takes two different functions that were both matching on `PatKind` to traverse subpatterns, and extracts the core match into a single helper function.
|
|
rustdoc-json: Add tests for `#[repr(...)]`
Works towards #137645 and #81359
Based on #138018, but with only the test changes. CC ```@obi1kenobi```
r? ```@GuillaumeGomez```
|
|
Implement `read_buf` for Hermit
Following https://github.com/hermit-os/kernel/pull/1606, it is now safe to implement `Read::read_buf` for file descriptors on Hermit.
cc ```@mkroening```
|
|
Leave a breadcrumb towards bootstrap config documentation in `bootstrap.toml`
I was curious as to the possible bootstrap options I can put in config.toml, but had some trouble figuring it out. There is no obvious documentation in `config.toml` (obviously), the documentation in src/bootstrap/defaults is *nice*, but also rather sparse, by design.
I had to dive into the parsing code, and stuble upon [a very helpful doc comment](https://github.com/rust-lang/rust/blob/30f168ef811aec63124eac677e14699baa9395bd/src/bootstrap/src/core/config/config.rs#L181) there to realize that `config.example.toml` *exists*, and that it does, indeed, answer all of my questions.
So I figured it might be worth making this journey a bit easier for future contributors and add mention the `config.example.toml` directly in `config.toml`.
Now, since #137081 is in-flight which would rename `config(.example)?.toml` to `bootstrap(.example)?.toml`, I figure it's better to wait until that one lands, and submit the "new", "correct" filename upfront, instead of landing `config.toml` now and updating it to `boostrap.toml` later.
`@rustbot` blocked #137081
|
|
exit: document interaction with C
Cc https://github.com/rust-lang/rust/issues/126600
|
|
uefi: fs: Implement exists
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators.
This is an effort to break the original PR (https://github.com/rust-lang/rust/pull/129700) into much smaller chunks for faster upstreaming.
|
|
|
|
Rustc pull
|
|
Rollup of 7 pull requests
Successful merges:
- #138384 (Move `hir::Item::ident` into `hir::ItemKind`.)
- #138508 (Clarify "owned data" in E0515.md)
- #138531 (Store test diffs in job summaries and improve analysis formatting)
- #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly)
- #138556 (Fix ICE: attempted to remap an already remapped filename)
- #138608 (rustc_target: Add target feature constraints for LoongArch)
- #138619 (Flatten `if`s in `rustc_codegen_ssa`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by
classifying if the Path is Shell mapping, text representation of device
path protocol, or a relative path and converts into an absolute text
representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the
device path protocol prefix (similar to Windows drive). After that, it
opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions
to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the
memory contiguously and thus can be modeled using iterators.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
|
|
r=wesleywiser,jieyouxu
Mangle rustc_std_internal_symbols functions
This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`.
Helps mitigate https://github.com/rust-lang/rust/issues/104707
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: x86_64-apple-1
try-job: x86_64-mingw-1
try-job: i686-mingw-1
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: test-various
try-job: armhf-gnu
|
|
Flatten `if`s in `rustc_codegen_ssa`
Best viewed [while ignoring whitespace](https://github.com/rust-lang/rust/pull/138619/files?diff=unified&w=1)
|
|
rustc_target: Add target feature constraints for LoongArch
Part of https://github.com/rust-lang/rust/issues/116344
r? `@RalfJung`
|
|
r=GuillaumeGomez,Urgau
Fix ICE: attempted to remap an already remapped filename
This commit fixes an internal compiler error (ICE) that occurs when
rustdoc attempts to process macros with a remapped filename. The issue
arose during macro expansion when the `--remap-path-prefix` option was
used.
Instead of passing remapped filenames through, which would trigger the
"attempted to remap an already remapped filename" panic, we now
extract the original local path from remapped filenames before
processing them.
A test case has been added to verify this behavior.
Fixes #138520
|
