[pull] master from rust-lang:master #12
Open
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Mark-Simulacrum
force-pushed
the
master
branch
from
47c0792
to
999ac5f
Compare
Use `ChunkedBitSet` instead.
It's no longer used.
This is in a test where the arrangement of backticks matters, but the exact words do not.
Remove `HybridBitSet` `HybridBitSet` was introduced under the name `HybridIdxSetBuf` way back in #53383 where it was a big win for NLL borrow checker performance. In #93984 the more flexible `ChunkedBitSet` was added. Uses of `HybridBitSet` have gradually disappeared (e.g. #116152) and there are now few enough that they can be replaced with `BitSet` or `ChunkedBitSet`, and `HybridBitSet` can be removed, cutting more than 700 lines of code. r? `@Mark-Simulacrum`
improvements on initial sysroot and libdir finding logics Stabilized initial sysroot and libdir path resolution logic to work without dry-run conditions and utilized initial sysroot more broadly.
Fix typos in pin.rs
bootstrap: allow skipping steps with start of path
support revealing defined opaque post borrowck By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. ``@compiler-errors`` mentioned that always using existentials may be unsound. r? ``@compiler-errors``
Use consistent wording in docs, use is zero instead of is 0 In documentation, wording of _"`rhs` is zero"_ and _"`rhs` is 0"_ is intermixed. This is especially visible [here](https://doc.rust-lang.org/std/primitive.usize.html#method.div_ceil). This changes all occurrences to _"`rhs` is zero"_ for better readability.
Better diagnostic for fn items in variadic functions closes #69232
Rename `-Zparse-only` It's a misleading name. r? ````@estebank````
The link was introduced in 0ec321f. For the old link see https://web.archive.org/web/20170409223244/https://monoinfinito.wordpress.com/series/exception-handling-in-c/. The blog has migrated from WordPress to Blogger in 2021 and to GitHub pages in 2024.
and add a test for the constant case
we store overflow errors locally, even if we can otherwise use the global cache for this goal.
Rollup of 7 pull requests Successful merges: - #132782 (improvements on initial sysroot and libdir finding logics) - #133466 (Fix typos in pin.rs) - #133492 (bootstrap: allow skipping steps with start of path) - #133501 (support revealing defined opaque post borrowck) - #133530 (Use consistent wording in docs, use is zero instead of is 0) - #133538 (Better diagnostic for fn items in variadic functions) - #133590 (Rename `-Zparse-only`) r? `@ghost` `@rustbot` modify labels: rollup
This context is stored in `CodegenCx`, which makes it per-CGU rather than per-crate. A single crate can have multiple CGUs.
There is unlikely to be any practical difference between a counter limit of 2^32 and a counter limit of (2^32 - 256).
This is currently handled automatically by the fact that codegen doesn't visit coverage statements in unused functions, but that will no longer be the case when unused IDs are identified by a separate query instead.
Support `clobber_abi` in AVR inline assembly This PR implements the `clobber_abi` part necessary to eventually stabilize the inline assembly for AVR. This is tracked in #93335. This is heavily inspired by the sibling-PR #131310 for the MSP430. I've explained my reasoning in the first commit message in detail, which is reproduced below for easier reviewing: This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call-clobbered, but this knowledge is not exposed explicitly to the compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways). Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers r? ``@Amanieu`` ``@rustbot`` label +O-AVR
[rustdoc] Change impl items indent Fixes #131704. | before | after | |-|-| |  |  | Can be tested [here](https://rustdoc.crud.net/imperio/impl-items-indent/bar/struct.Bar.html). r? `@notriddle`
chore: fix 404 status URL
Rollup of 10 pull requests Successful merges: - #131713 (Stabilize `const_maybe_uninit_write`) - #133535 (show forbidden_lint_groups in future-compat reports) - #133610 (Move `Const::{from_anon_const,try_from_lit}` to hir_ty_lowering) - #133701 (Use c"lit" for CStrings without unwrap) - #133704 (fix ICE when promoted has layout size overflow) - #133705 (add "profiler" and "optimized-compiler-builtins" option coverage for ci-rustc) - #133710 (Reducing `target_feature` check-cfg merge conflicts) - #133732 (Fix `-Zdump-mir-dataflow`) - #133746 (Change `AttrArgs::Eq` to a struct variant) - #133763 (Fix `f16::midpoint` const feature gate) r? `@ghost` `@rustbot` modify labels: rollup
Get rid of HIR const checker As far as I can tell, the HIR const checker was implemented in #66170 because we were not able to issue useful const error messages in the MIR const checker. This seems to have changed in the last 5 years, probably due to work like #90532. I've tweaked the diagnostics slightly and think the error messages have gotten *better* in fact. Thus I think the HIR const checker has reached the end of its usefulness, and we can retire it. cc `@RalfJung`
…onur-ozkan
Unify `sysroot_target_{bin,lib}dir` handling
Follow-up to #131405 (comment) where `sysroot_target_bindir` had to do some dancing because the sysroot ensure logic embedded in `sysroot_target_libdir` returned `$sysroot/$relative_lib/rustlib/$target/lib` and not the `rustlib` parent `$sysroot/$relative_lib/rustlib/`.
This PR pulls out the sysroot ensure logic into a helper, and return `$sysroot/$relative_lib/rustlib/` instead so `sysroot_target_bindir` doesn't have to do parent traversal from the path returned from `sysroot_target_libdir`, and also make them easier to follow in that they are now clearly closely related based on the common target sysroot ensure logic.
…davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. ``@BlackHoleFox`` wdyt? ``@rustbot`` label O-apple r? compiler
Reimplement `~const` trait specialization Reimplement const specialization. We need this for `PartialEq` constification :) r? lcnr
…bilee Add simd_relaxed_fma intrinsic Adds compiler support for rust-lang/portable-simd#387 (comment) r? `@workingjubilee` cc `@RalfJung` is this kind of nondeterminism a problem for miri/opsem?
Deeply normalize when computing implied outlives bounds r? lcnr Unfortunately resolving regions is still slightly scuffed (though in an unrelated way). Specifically, we should be normalizing our param-env outlives when constructing the `OutlivesEnv`; otherwise, these assumptions (https://github.com/rust-lang/rust/blob/dd2837ec5de4301a692e05a7c4475e980af57a57/compiler/rustc_infer/src/infer/outlives/env.rs#L78) are not constructed correctly. Let me know if you want us to track that somewhere.
Add const evaluation error UI test. This closes #78834
Rollup of 6 pull requests Successful merges: - #132723 (Unify `sysroot_target_{bin,lib}dir` handling) - #133041 (Print name of env var in `--print=deployment-target`) - #133325 (Reimplement `~const` trait specialization) - #133395 (Add simd_relaxed_fma intrinsic) - #133517 (Deeply normalize when computing implied outlives bounds) - #133785 (Add const evaluation error UI test.) r? `@ghost` `@rustbot` modify labels: rollup
…esleywiser Require `type_map::stub` callers to supply file information This change attaches file information (`DIFile` reference and line number) to struct debug info nodes. Before: ``` ; foo.ll ... !5 = !DIFile(filename: "<unknown>", directory: "") ... !16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !5, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "4cb373851db92e732c4cb5651b886dd0") ... ``` After: ``` ; foo.ll ... !3 = !DIFile(filename: "foo.rs", directory: "/home/matt/src/rust98678", checksumkind: CSK_SHA1, checksum: "bcb9f08512c8f3b8181ef4726012bc6807bc9be4") ... !16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !3, line: 3, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "9e5968c7af39c148acb253912b7f409f") ... ``` Fixes #98678 r? `@wesleywiser`
This ensures that it matches the one in `carrying_add`.
switch `jemalloc-sys` back to `tikv-jemalloc-sys`, and update to 0.6.0 Some context: - we used to use jemalloc bindings from https://github.com/gnzlbg/jemallocator, since #55238 - that crate was abandoned, picked up as a fork in https://github.com/tikv/jemallocator, so we switched to that in #83152. - then they were able to publish to the original `jemalloc-sys` bindings crate, and `jemalloc-sys` and `tikv-jemalloc-sys` became the same thing -- so I switched back to the OG crate in #96790 - they're now having publishing problems again: I've been waiting for tikv/jemallocator#96 for the `jemalloc-sys` 0.6.0 update for a few months, but `tikv-jemalloc-sys` is already updated to 0.6.0. A perf run showed some improvements, so this PR switches back to `tikv-jemalloc-sys` to update to 0.6.0.
Gate async fn trait bound modifier on `async_trait_bounds` This PR moves `async Fn()` trait bounds into a new feature gate: `feature(async_trait_bounds)`. The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier, so we need to gate that separately. We're trying to work on the general vision of `async` trait bound modifier general in: rust-lang/rfcs#3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
Lint against Symbol::intern on a string literal Disabled in tests where this doesn't make much sense
…adt, r=lcnr Structurally resolve in `probe_adt` fixes #132320 r? lcnr
stabilize const_collections_with_hasher and build_hasher_default_const_new After a lot of preparatory work, finally we can stabilize creating `HashMap` in const context. :) FCP for const_collections_with_hasher passed in #102575. Fixes #102575. FCP for build_hasher_default_const_new passed in #123197. Fixes #123197. Cc `@Amanieu` Release notes: #133347
…et-rescope, r=jieyouxu Reduce false positives on some common cases from if-let-rescope lint r? `@jieyouxu` We would like to identify a very common case in the ecosystem in which we do not need to apply the lint suggestion for the new Edition 2024 `if let` semantics. In this patch we excluded linting from `if let`s in statements and block tail expressions. In these simple cases, new Edition 2024 drop orders are identical to those of Edition 2021 and prior. However, conservatively we should still lint for the other cases, because [this example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2113df5ce78f161d32a1190faf5c7469) shows that the drop order changes are very pronounced, some of which are even sensitive to runtime data.
stabilize const_{size,align}_of_val
FCP passed [here](#46571 (comment)).
Fixes #46571.
…piler-errors Use correct `hir_id` for array const arg infers Fixes #133771 `self.next_id()` results in the `DefId` for the const argument, created from the hack introduced by #133468, having no `HirId` associated with it. This then results in an ICE in metadata encoding. Fixing this then results in *another* ICE where `encode_defs` was not skipping encoding `type_of` and other queries for `DefId`s when they correspond to a `ConstArgKind::Infer` node. This only reproduces with a library crate as metadata is not encoded for binaries, and apparently we had 0 tests for `generic_arg_infer` for array lengths in a library crate so this was not caught :< cc #133589 `@voidc` r? `@compiler-errors` `@lcnr`
Update the definition of `borrowing_sub` Complementary PR to #133674, which only updated `carrying_add`.
Rollup of 9 pull requests Successful merges: - #132612 (Gate async fn trait bound modifier on `async_trait_bounds`) - #133545 (Lint against Symbol::intern on a string literal) - #133558 (Structurally resolve in `probe_adt`) - #133696 (stabilize const_collections_with_hasher and build_hasher_default_const_new) - #133753 (Reduce false positives on some common cases from if-let-rescope lint) - #133762 (stabilize const_{size,align}_of_val) - #133777 (document -Zrandomize-layout in the unstable book) - #133779 (Use correct `hir_id` for array const arg infers) - #133796 (Update the definition of `borrowing_sub`) r? `@ghost` `@rustbot` modify labels: rollup
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )