Rustc pull #2313
Merged
Rustc pull #2313
+50
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Move `hir::Item::ident` into `hir::ItemKind`.
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`, `Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for `UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single comment saying "The name might be a dummy name in case of anonymous items". Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out.
This is step towards `kw::Empty` elimination (#137978).
r? `@fmease`
Clarify "owned data" in E0515.md This clarifies the explanation of why this is not allowed and also what to do instead. Fixes #62071 PS There was suggestion of adding a link to the book. I did not yet do that, but if desired that could be added.
Store test diffs in job summaries and improve analysis formatting This PR stores the test diffs that we already have in the post-merge workflow also into individual job summaries. This makes it easier to compare test (and later also other) diffs per job, which will be especially useful for try jobs, so that we can actually see the test diffs *before* we merge a given PR. As a drive-by, I also made a bunch of cleanups in `citool` and in the formatting of the summary and post-merge analyses. These changes are split into self-contained commits. The analysis can be tested locally with the following command: ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/<current-sha>/metrics-<job-name>.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name <job-name> --parent <parent-sha> > out.md ``` For example, for [this PR](rust-lang/rust#138523): ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/282865097d138c7f0f7a7566db5b761312dd145c/metrics-aarch64-gnu.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name aarch64-gnu --parent d9e5539a39192028a7b15ae596a8685017faecee > out.md ``` Best reviewed commit by commit. r? `@marcoieni` try-job: aarch64-gnu try-job: dist-x86_64-linux
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job). This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations). I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist. Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR): - If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible. - If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case. In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits. r? `@marcoieni`
…laumeGomez,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
rustc_target: Add target feature constraints for LoongArch Part of rust-lang/rust#116344 r? `@RalfJung`
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)
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
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 (rust-lang/rust#129700) into much smaller chunks for faster upstreaming.
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
clarify BufRead::{fill_buf, consume} docs
Fixes #85394
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.
rustc-dev-guide sync r? `@jieyouxu`
Remove double nesting in post-merge workflow See [this](rust-lang/rust#138630 (comment)) :) 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`
CI: mirror alpine and centos images to ghcr
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.
…chenkov Revert: Add *_value methods to proc_macro lib This reverts rust-lang/rust#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 rust-lang/rust#138647 for context. Cc `@GuillaumeGomez` `@Amanieu`
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
Various codegen_llvm cleanups Mostly just adding safe wrappers and deduplicating code
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
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
Represent diagnostic side effects as dep nodes This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index. Some implications of this: - Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that. - Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks. - Reusing a CGU will now emit diagnostics from the task generating it.
…-19, r=workingjubilee Portable SIMD subtree update
Update to LLVM 20.1.1 Fixes rust-lang/rust#138212. Fixes rust-lang/rust#137909.
Consider fields to be inhabited if they are unstable Fixes #133885 with a simple heuristic r? Nadrieril Not totally certain if this needs T-lang approval or a crater run.
Add support for postfix yield expressions We've been having a discussion about whether we want postfix yield, or want to stick with prefix yield, or have both. I figured it's easy enough to support both for now and let us play around with them while the feature is still experimental. This PR treats `yield x` and `x.yield` as semantically equivalent. There was a suggestion to make `yield x` have a `()` type (so it only works in coroutines with `Resume = ()`. I think that'd be worth trying, either in a later PR, or before this one merges, depending on people's opinions. #43122
…ram-names, r=compiler-errors Use `Option<Ident>` for lowered param names. Parameter patterns are lowered to an `Ident` by `lower_fn_params_to_names`, which is used when lowering bare function types, trait methods, and foreign functions. Currently, there are two exceptional cases where the lowered param can become an empty `Ident`. - If the incoming pattern is an empty `Ident`. This occurs if the parameter is anonymous, e.g. in a bare function type. - If the incoming pattern is neither an ident nor an underscore. Any such parameter will have triggered a compile error (hence the `span_delayed_bug`), but lowering still occurs. This commit replaces these empty `Ident` results with `None`, which eliminates a number of `kw::Empty` uses, and makes it impossible to fail to check for these exceptional cases. Note: the `FIXME` comment in `is_unwrap_or_empty_symbol` is removed. It actually should have been removed in #138482, the precursor to this PR. That PR changed the lowering of wild patterns to `_` symbols instead of empty symbols, which made the mentioned underscore check load-bearing. r? ``@compiler-errors``
Suggest `-Whelp` when pass `--print lints` to rustc Closes #138612
hygiene: Ensure uniqueness of `SyntaxContextData`s `SyntaxContextData`s are basically interned with `SyntaxContext`s working as indices, so they are supposed to be unique. However, currently duplicate `SyntaxContextData`s can be created during decoding from metadata or incremental cache. This PR fixes that. cc rust-lang/rust#129827 (comment)
Remove `prev_index_to_index` field from `CurrentDepGraph` The dep graph currently has 2 ways to map a previous index into a current index. The `prev_index_to_index` map stores the current index equivalent of a previous index. For indices which are marked green, we also store the same information in the `DepNodeColorMap`. We actually only need to known the mapping for green nodes however, so this PR removes `prev_index_to_index` and instead makes use of the `DepNodeColorMap`. To avoid racing when promoting a node from the previous session, the encoder lock is now used to ensure only one thread encodes the promoted node. This was previously done by the lock in `prev_index_to_index`. This also changes `nodes_newly_allocated_in_current_session` used to detect duplicate dep nodes to contain both new and previous nodes, which is simpler and can better catch duplicates. The dep node index encoding used in `DepNodeColorMap` is tweak to avoid subtraction / addition to optimize accessing the current equivalent of a previous index. r? `@oli-obk`
Instantiate binder before registering nested obligations for auto/built-in traits Instead of turning a `Binder<Vec<Ty>>` into a bunch of higher-ranked predicates, instantiate the binder eagerly *once* and turn them into a bunch of non-higher-ranked predicates. Right now this feels like a noop, but this `enter_forall_and_leak_universe` call would be the singular place where we could instantiate bound lifetime assumptions for coroutine witnesses... if we had them. Thus consolidating the binder instantiation here is useful if we want to fix the coroutine-auto-trait problem. r? lcnr
…aumeGomez rustdoc: Rearrange `Item`/`ItemInner`. The `Item` struct is 48 bytes and contains a `Box<ItemInner>`; `ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd have one of the following. - A single large struct, which avoids the allocation for the `Box`, but can result in lots of wasted space in unused parts of a container like `Vec<Item>`, `HashSet<Item>`, etc. - Or, something like `struct Item(Box<ItemInner>)`, which requires the `Box` allocation but gives a very small Item size, which is good for containers like `Vec<Item>`. `Item`/`ItemInner` currently gets the worst of both worlds: it always requires a `Box`, but `Item` is also pretty big and so wastes space in containers. It would make sense to push it in one direction or the other. #138916 showed that the first option is a regression for rustdoc, so this commit does the second option, which improves speed and reduces memory usage. r? `@GuillaumeGomez`
Allow spawning threads after TLS destruction Fixes #138696
Avoid wrapping constant allocations in packed structs when not necessary This way LLVM will set the string merging flag if the alloc is a nul terminated string, reducing binary sizes. try-job: armhf-gnu
Implement `alloc::sync::UniqueArc` This implements the `alloc::sync::UniqueArc` part of #112566.
stabilize const_cell
``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` I see no reason to wait any longer, so I propose we stabilize the use of `Cell` in `const fn` -- specifically the APIs listed here:
```rust
// core::cell
impl<T> Cell<T> {
pub const fn replace(&self, val: T) -> T;
}
impl<T: Copy> Cell<T> {
pub const fn get(&self) -> T;
}
impl<T: ?Sized> Cell<T> {
pub const fn get_mut(&mut self) -> &mut T;
pub const fn from_mut(t: &mut T) -> &Cell<T>;
}
impl<T> Cell<[T]> {
pub const fn as_slice_of_cells(&self) -> &[Cell<T>];
}
```
Unfortunately, `set` cannot be made `const fn` yet as it drops the old contents.
Fixes rust-lang/rust#131283
Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu
Start using `with_native_path` in `std::sys::fs` Ideally, each platform should use their own native path type internally. This will, for example, allow passing a `CStr` directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated C string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this PR does some minimal refactoring which should help progress towards that goal. The changes are Unix-only and even then I avoided functions that require more changes so that this PR is just moving things around. r? joboet
compiletest: Support matching diagnostics on lines below Using `//~vvv ERROR`. This is not needed often, but it's easy to support, and it allows to eliminate a class of `error-pattern`s that cannot be eliminated in any other way. See the diff for the examples of such patterns coming from parser. Some of them can be matched by `//~ ERROR` or `//~^ ERROR` as well (when the final newline is allowed), but it changes the shape of reported spans, so I chose to keep the spans by using `//~v ERROR`.
…rors `BackendRepr::is_signed`: comment why this may panics Was wondering why this method could panics while the others couldn't, so quote PR #70189.
Mark .pp files as Rust Pretty-printing tests generate `.pp` files, but GitHub classify and highlight them as Pascal: [https://github.com/search?q=repo:rust-lang/rust+path:*.pp&type=code](https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A*.pp&type=code) ``@rustbot`` label +A-meta +A-testsuite
Rollup of 7 pull requests Successful merges: - #137928 (stabilize const_cell) - #138431 (Fix `uclibc` LLVM target triples) - #138832 (Start using `with_native_path` in `std::sys::fs`) - #139081 (std: deduplicate `errno` accesses) - #139100 (compiletest: Support matching diagnostics on lines below) - #139105 (`BackendRepr::is_signed`: comment why this may panics) - #139106 (Mark .pp files as Rust) r? `@ghost` `@rustbot` modify labels: rollup
rustc_target: Add more RISC-V vector-related features and use zvl*b target features in vector ABI check Currently, we have only unstable `v` target feature, but RISC-V have more vector-related extensions. The first commit of this PR adds them to unstable `riscv_target_feature`. - `unaligned-vector-mem`: Has reasonably performant unaligned vector - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L1379) - Similar to currently unstable `unaligned-scalar-mem` target feature, but for vector instructions. - `zvfh`: Vector Extension for Half-Precision Floating-Point - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfh-vector-extension-for-half-precision-floating-point) - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L668) - This implies `zvfhmin` and `zfhmin` - `zvfhmin`: Vector Extension for Minimal Half-Precision Floating-Point - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point) - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L662) - This implies `zve32f` - `zve32x`, `zve32f`, `zve64x`, `zve64f`, `zve64d`: Vector Extensions for Embedded Processors - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zve-vector-extensions-for-embedded-processors) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L612-L641) - `zve32x` implies `zvl32b` - `zve32f` implies `zve32x` and `f` - `zve64x` implies `zve32x` and `zvl64b` - `zve64f` implies `zve32f` and `zve64x` - `zve64d` implies `zve64f` and `d` - `v` implies `zve64d` - `zvl*b`: Minimum Vector Length Standard Extensions - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvl-minimum-vector-length-standard-extensions) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L600-L610) - `zvl{N}b` implies `zvl{N>>1}b` - `v` implies `zvl128b` - Vector Cryptography and Bit-manipulation Extensions - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/vector-crypto.adoc) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L679-L807) - `zvkb`: Vector Bit-manipulation used in Cryptography - This implies `zve32x` - `zvbb`: Vector basic bit-manipulation instructions - This implies `zvkb` - `zvbc`: Vector Carryless Multiplication - This implies `zve64x` - `zvkg`: Vector GCM instructions for Cryptography - This implies `zve32x` - `zvkned`: Vector AES Encryption & Decryption (Single Round) - This implies `zve32x` - `zvknha`: Vector SHA-2 (SHA-256 only)) - This implies `zve32x` - `zvknhb`: Vector SHA-2 (SHA-256 and SHA-512) - This implies `zve64x` - This is superset of `zvknha`, but doesn't imply that feature at least in LLVM - `zvksed`: SM4 Block Cipher Instructions - This implies `zve32x` - `zvksh`: SM3 Hash Function Instructions - This implies `zve32x` - `zvkt`: Vector Data-Independent Execution Latency - Similar to already stabilized scalar cryptography extension `zkt`. - `zvkn`: Shorthand for 'Zvkned', 'Zvknhb', 'Zvkb', and 'Zvkt' - Similar to already stabilized scalar cryptography extension `zkn`. - `zvknc`: Shorthand for 'Zvkn' and 'Zvbc' - `zvkng`: shorthand for 'Zvkn' and 'Zvkg' - `zvks`: shorthand for 'Zvksed', 'Zvksh', 'Zvkb', and 'Zvkt' - Similar to already stabilized scalar cryptography extension `zks`. - `zvksc`: shorthand for 'Zvks' and 'Zvbc' - `zvksg`: shorthand for 'Zvks' and 'Zvkg' Also, our vector ABI check wants `zvl*b` target features, the second commit of this PR updates vector ABI check to use them. https://github.com/rust-lang/rust/blob/4e2b096ed6c8a1400624a54f6c4fd0c0ce48a579/compiler/rustc_target/src/target_features.rs#L707-L708 --- r? `@Amanieu` `@rustbot` label +O-riscv +A-target-feature
Set `target_vendor = "openwrt"` on `mips64-openwrt-linux-musl` OpenWRT is a Linux distribution for embedded network devices. The target name contains `openwrt`, so we should set `cfg(target_vendor = "openwrt")`. This is similar to what other Linux distributions do (the only one in-tree is `x86_64-unikraft-linux-musl`, but that sets `target_vendor = "unikraft"`). Motivation: To make correctly [parsing target names](rust-lang/cc-rs#1413) simpler. Fixes rust-lang/rust#131165. CC target maintainer `@Itus-Shield`
…nore-packed-align, r=workingjubilee [AIX] Ignore linting on repr(C) structs with repr(packed) or repr(align(n)) This PR updates the lint added in 9b40bd7 to ignore repr(C) structs that also have repr(packed) or repr(align(n)). As these representations can be modifiers on repr(C), it is assumed that users that add these should know what they are doing, and thus the the lint should not warn on the respective structs. For example, for the time being, using repr(packed) and manually padding a repr(C) struct can be done to correctly align struct members on AIX.
…acrum
Simplify expansion for format_args!().
Instead of calling `Placeholder::new()`, we can just use a struct expression directly.
Before:
```rust
Placeholder::new(…, …, …, …)
```
After:
```rust
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
```
(I originally avoided the struct expression, because `Placeholder` had a lot of fields. But now that rust-lang/rust#136974 is merged, it only has four fields left.)
This will make the `fmt` argument to `fmt::Arguments::new_v1_formatted()` a candidate for const promotion, which is important if we ever hope to tackle rust-lang/rust#92698 (It doesn't change anything yet though, because the `args` argument to `fmt::Arguments::new_v1_formatted()` is not const-promotable.)
Uplift `clippy::invalid_null_ptr_usage` lint as `invalid_null_arguments` This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](rust-lang/rust#111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one. *For context: GitHub Search reveals that just for `slice::from_raw_parts{_mut}` [~20 invalid usages](hhttps://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%28_mut%29%3F%5C%28ptr%3A%3Anull%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F&type=code) with `ptr::null` and an additional [4 invalid usages](https://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%5C%280%28%5C%29%7C+as%29%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Ftinystr%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Fzerovec%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eprovider%5C%2Fcore%5C%2Fsrc%5C%2F%2F&type=code) with `0 as *const ...`-ish casts.* ----- ## `invalid_null_arguments` (deny-by-default) The `invalid_null_arguments` lint checks for invalid usage of null pointers. ### Example ```rust // Undefined behavior unsafe { std::slice::from_raw_parts(ptr::null(), 1); } ``` Produces: ``` error: calling this function with a null pointer is Undefined Behavior, even if the result of the function is unused --> $DIR/invalid_null_args.rs:21:23 | LL | let _: &[usize] = std::slice::from_raw_parts(ptr::null_mut(), 0); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------^^^^ | | | null pointer originates from here | = help: for more information, visit <https://doc.rust-lang.org/std/ptr/index.html> and <https://doc.rust-lang.org/reference/behavior-considered-undefined.html> ``` ### Explanation Calling methods whose safety invariants requires non-null pointer with a null pointer is undefined behavior. ----- The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute. This PR also includes some small refactoring to avoid some ambiguities in naming, those can be done in another PR is desired. `@rustbot` label: +I-lang-nominated r? compiler
hygiene: Rewrite `apply_mark_internal` to be more understandable The previous implementation allocated new `SyntaxContext`s in the inverted order, and it was generally very hard to understand why its result matches what the `opaque` and `opaque_and_semitransparent` field docs promise. ```rust /// This context, but with all transparent and semi-transparent expansions filtered away. opaque: SyntaxContext, /// This context, but with all transparent expansions filtered away. opaque_and_semitransparent: SyntaxContext, ``` It also couldn't be easily reused for the case where the context id is pre-reserved like in #129827. The new implementation tries to follow the docs in a more straightforward way. I did the transformation in small steps, so it indeed matches the old implementation, not just the docs. So I suggest reading only the new version.
Revert "Rollup merge of #136127 - WaffleLapkin:dyn_ptr_unwrap_cast, r=compiler-errors" ...not permanently tho. Just until we can land something like #138542, which will fix the underlying perf issues (rust-lang/rust#136127 (comment)). I just don't want this to land on beta and have people rely on this behavior if it'll need some reworking for it to be implemented performantly. r? `@WaffleLapkin` or reassign -- sorry for reverting ur pr! i'm working on getting it re-landed soon :>
remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc `@rust-lang/types` `@rust-lang/lang` #76001
Fix UWP reparse point check Fixes #138921
jieyouxu
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Manual rustc-pull because there are some important compiletest ui test annotation changes.