[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
…rrors cleanup promoteds move check r? types
Make tidy warn on unrecognized directives This PR makes it so tidy warns on unrecognized directives, as recommended on [the discussion of #130984](#130984 (comment)). This is edited from the previous version of this PR, which only warned on "tidy-ignore" and no other tidy directive typos. Fixes #130984. ``@rustbot`` label A-tidy C-enhancement
…li-obk Remove unnecessary assertion for reference error Fixes #135341 From comment: #135341 (comment) r? ``@oli-obk``
ci: improve github action name
new solver: prefer trivial builtin impls As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/needs_help.3A.20trivial.20builtin.20impls), this PR: - adds a new `BuiltinImplSource::Trivial` source, and marks the `Sized` builtin impls as trivial - prefers these trivial builtin impls in `merge_trait_candidates` The comments can likely be wordsmithed a bit better, and I ~stole~ was inspired by the old solver ones. Let me know how you want them improved. When enabling the new solver for tests, 3 UI tests now pass: - `regions/issue-26448-1.rs` and its sibling `regions/issue-26448-2.rs` were rejected by the new solver but accepted by the old one - and `issues/issue-42796.rs` where the old solver emitted some overflow errors in addition to the expected error (For some reason one of these tests is run-pass, but I can take care of that another day) r? lcnr
add src/librustdoc and src/rustdoc-json-types to RUSTC_IF_UNCHANGED_ALLOWED_PATHS fixes #135650 r? ``@onur-ozkan``
Bump Fuchsia integration commit This advances Fuchsia to a checkout from 2025-01-13, which corresponds to a recent Rust roll, and hopefully avoids #135667, where a repository used by the older version of Rust was accidentally archived and broke checking out the prior version. try-job: x86_64-fuchsia cc `@ehuss`
- Move `make_bcb_counters` out of `CoverageCounters` - Split out `make_node_counter_priority_list` - Flatten `Transcriber` into the function `transcribe_counters`
Making these separate types from `CovTerm` and `Expression` was historically very helpful, but now that most of the counter-creation work is handled by `node_flow` they are no longer needed.
fix: `cargo rustc --print` needs `unstable-options`
Rollup of 6 pull requests Successful merges: - #134455 (cleanup promoteds move check) - #135421 (Make tidy warn on unrecognized directives) - #135611 (Remove unnecessary assertion for reference error) - #135620 (ci: improve github action name) - #135639 (new solver: prefer trivial builtin impls) - #135654 (add src/librustdoc and src/rustdoc-json-types to RUSTC_IF_UNCHANGED_ALLOWED_PATHS) r? `@ghost` `@rustbot` modify labels: rollup
const-eval: detect more pointers as definitely not-null This fixes #133523 by making the `scalar_may_be_null` check smarter: for instance, an odd offset in any 2-aligned allocation can never be null, even if it is out-of-bounds. More generally, if an allocation with unknown base address B is aligned to alignment N, and a pointer is at offset X inside that allocation, then we know that `(B + X) mod N = B mod N + X mod N = X mod N`. Since `0 mod N` is definitely 0, if we learn that `X mod N` is *not* 0 we can deduce that `B + X` is not 0. This is immediately visible on stable, via `ptr.is_null()` (and, more subtly, by not raising a UB error when such a pointer is used somewhere that a non-null pointer is required). Therefore nominating for `@rust-lang/lang.`
Encode constraints that hold at all points as logical edges in location-sensitive polonius Currently, with the full setup in #134980 (but is from #134268), the polonius location-sensitive analysis converts `Locations::All` typeck constraints as edges at all points in the CFG. This was temporary. There's a FIXME about that already, and this PR implements it: we now use the constraints that hold at all points during traversal instead of eagerly materializing them as physical edges. Another easy one `@jackh726.` This fixes the slowness that was happening on the big CFG from the `saturating-float-casts` test (because of its 12M materialized edges) without, AFAICT, simply moving this overhead to traversal: materializing the logical edges is done on-demand. r? `@jackh726` (no rush either)
Run clippy for rustc_codegen_gcc on CI Requested on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Run.20clippy.20for.20rustc_codegen_gcc.20in.20the.20Rust.20CI). Opening as a draft, since it's not clear which rules should be applied to it. r? `@ghost`
Move `std::pipe::*` into `std::io` Resolve concern from final comment period #127154 (comment)
…=clubby789 Include x scripts in tarballs Helps to provide 1:1 build experience between git-managed and tarball sources.
ci: mirror buildkit image to ghcr
…ottmcm Stabilize `float_next_up_down` FCP completed at [1]. For `f16` and `f128`, this just removes the gates in comments and doctests. Closes #91399 [1]: #91399 (comment)
Update cargo 13 commits in 088d496082726091024f1689c124a0c3dccbd775..045bf21b36a2e1f3ed85e38278d1c3cc4305e134 2025-01-10 20:10:21 +0000 to 2025-01-17 14:59:36 +0000 - created a function for user defined aliases (rust-lang/cargo#15076) - took the functionality of the third party subcommand from the list_commands function (rust-lang/cargo#15075) - fix: wrong concat and field name (rust-lang/cargo#15074) - fix(publish): Report all unpublishable packages (rust-lang/cargo#15070) - docs(cargo-clippy): correct typo (rust-lang/cargo#15072) - docs(cargo-package): alwasy include the lockfile (rust-lang/cargo#15067) - docs(ref): Deprecate 'package.authors' (rust-lang/cargo#15068) - fix(build-std): parse as comma-separated list (rust-lang/cargo#15065) - Fix benchsuite issue with newer versions of git (rust-lang/cargo#15069) - Document that cargo automatically registers variables used in env! macro to trigger rebuilds (rust-lang/cargo#15062) - perf(cargo-package): match certain path prefix with pathspec (rust-lang/cargo#14997) - Clarify note in example (rust-lang/cargo#15054) - chore(deps): update msrv (3 versions) to v1.82 (rust-lang/cargo#15050)
Update syntax tree viewer docs
Properly record metavar spans for other expansions other than TT This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result. Fixes #132908 Alternative to #133270 cc `@ehuss` cc `@petrochenkov`
This CL makes a number of small changes to dyn compatibility errors: - "object safety" has been renamed to "dyn-compatibility" throughout - "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait` - Several error messages are reorganized for user readability Additionally, the dyn compatibility error creation code has been split out into functions. cc #132713 cc #133267
Refactor dyn-compatibility error and suggestions This CL makes a number of small changes to dyn compatibility errors: - "object safety" has been renamed to "dyn-compatibility" throughout - "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait` - Several error messages are reorganized for user readability Additionally, the dyn compatibility error creation code has been split out into functions. cc #132713 cc #133267 r? `@compiler-errors`
…=wesleywiser AIX: use align 8 for byval parameter On AIX, byval pointer arguments are aligned to 8 bytes based on the 64bit register size. For example, the C callee https://godbolt.org/z/5f4vnG6bh will expect the following argument. ``` ptr nocapture noundef readonly byval(%struct.TwoU64s) align 8 %0 ``` This case is captured by `run-make/extern-fn-explicit-align`
Make our `DIFlags` match `LLVMDIFlags` in the LLVM-C API In order to be able to use a mixture of LLVM-C and C++ bindings for debuginfo, our Rust-side `DIFlags` needs to have the same layout as LLVM-C's `LLVMDIFlags`, and we also need to be able to convert it to the `DIFlags` accepted by LLVM's C++ API. Internally, LLVM converts between the two types with a simple cast. We can't necessarily rely on that always being true, and LLVM doesn't expose a conversion function, so we have two potential options: - Convert each bit/subvalue individually - Statically assert that doing a cast is actually fine As long as both types do remain the same under the hood (which seems likely), the static-assert-and-cast approach is easier and faster. If the static assertions ever start failing against some future version of LLVM, we'll have to switch over to the convert-each-subvalue approach, which is a bit more error-prone. --- Extracted from #134009, though this PR ended up choosing the static-assert-and-cast approach over the convert-each-subvalue approach.
Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors r? `@lcnr` I added `structurally_normalize_term` so that code that is generic over ty or const can use the structurally normalize helpers. See `tests/ui/traits/next-solver/diagnostics/alias_relate_error_uses_structurally_normalize.rs` for a description of the reason for the (now fixed) ICEs
make UI tests that use `--test` work on panic=abort targets By passing `-Zpanic_abort_test`. fixes #135819
…eyouxu Update the `wasm-component-ld` tool This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12. This pulls in a fix for the binary adapters that are included with this tool for an issue described in bytecodealliance/wasmtime#10058. Some other dependencies have additionally been updated in the meantime of `wasm-component-ld` but there should otherwise be no major changes.
…=GuillaumeGomez rustdoc: Finalize dyn compatibility renaming Update the Reference link to use the new URL fragment from rust-lang/reference#1666 (this change has finally hit stable). Fixes a FIXME. Follow-up to #131594. Part of #130852.
Don't pick `T: FnPtr` nested goals as the leaf goal in diagnostics for new solver
r? `@lcnr`
See `tests/ui/traits/next-solver/diagnostics/dont-pick-fnptr-bound-as-leaf.rs` for a minimized example of what code this affects the diagnostics off. The output of running nightly `-Znext-solver` on that test is the following:
```
error[E0277]: the trait bound `Foo: Trait` is not satisfied
--> src/lib.rs:14:20
|
14 | requires_trait(Foo);
| -------------- ^^^ the trait `FnPtr` is not implemented for `Foo`
| |
| required by a bound introduced by this call
|
note: required for `Foo` to implement `Trait`
--> src/lib.rs:7:16
|
7 | impl<T: FnPtr> Trait for T {}
| ----- ^^^^^ ^
| |
| unsatisfied trait bound introduced here
note: required by a bound in `requires_trait`
--> src/lib.rs:11:22
|
11 | fn requires_trait<T: Trait>(_: T) {}
| ^^^^^ required by this bound in `requires_trait`
```
Part of rust-lang/trait-system-refactor-initiative#148
Enforce that all spans are lowered in ast lowering This should ensure that incremental is used as extensively as possible. It's only a debug assertion, and only enabled when incremental is enabled (as we only lower spans to relative spans then).
Remove `Copy` bound from `enter_forall` idk why we ever required this, `TypeFoldable` implies `Clone`
Rollup of 10 pull requests Successful merges: - #133372 (Refactor dyn-compatibility error and suggestions) - #134396 (AIX: use align 8 for byval parameter) - #135156 (Make our `DIFlags` match `LLVMDIFlags` in the LLVM-C API) - #135816 (Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors) - #135823 (make UI tests that use `--test` work on panic=abort targets) - #135850 (Update the `wasm-component-ld` tool) - #135858 (rustdoc: Finalize dyn compatibility renaming) - #135866 (Don't pick `T: FnPtr` nested goals as the leaf goal in diagnostics for new solver) - #135874 (Enforce that all spans are lowered in ast lowering) - #135875 (Remove `Copy` bound from `enter_forall`) r? `@ghost` `@rustbot` modify labels: rollup
Edit dangling pointers Closes: #132283
…start-block, r=Nadrieril Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block Fixes #133117 , and close fixes #133063 , fixes #130779 In order to fix ICE-133117, at first I needed to tackle to ICE-133063 (this fixed 130779 as well). ### ICE-133063 and ICE-130779 This ICE is caused by those steps: 1. An arm has or-pattern, and all of the sub-candidates are never-pattern 2. In that case, all sub-candidates are removed in remove_never_subcandidates(). So the arm (candidate) has no sub-candidate. 3. In the current implementation, if there is no sub-candidate, the function assigns `pre_binding_block` into the candidate ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L2002-L2004)). However, otherwise_block should be assigned to the candidate as well, because the otherwise_block is unwrapped in multiple place (like in lower_match_tree()). As a result, it causes the panic. I simply added the same block as pre_binding_block into otherwise_block, but I'm wondering if there is a better block to assign to otherwise_block (is it ok to assign the same block into pre_binding and otherwise?) ### ICE-133117 This is caused by those steps: 1. There are two arms, both are or-pattern and each has one match-pair (in the test code, both are `(!|!)`), and the second arm has a guard. 2. In match_candidate() for the first arm, it expands the second arm’s sub-candidates as well ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1800-L1805)). As a result, the root candidate of the second arm is not evaluated/modified in match_candidate(). So a false_edge_start_block is not assigned to the candidate. 3. merge_trivial_subcandidates() is called against the candidate for the second arm. It just returns immediately because the candidate has a guard. So a flase_edge_start_block is not assigned to the candidate also in this function. 4. remove_never_subcandidates() is called against the candidate. Since all sub-candidates are never-pattern. they are removed. 5. In lower_match_tree(), since there is no sub-candidate for the candidate, the candidate itself is evaluated in visit_leave_rev ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1532)). Because the candidate has no false_edge_start_block, it causes the panic. So I modified the order of if blocks in merge_trivial_subcandidates() to assign a false_edge_start_block if the candidate doesn't have.
Point at invalid utf-8 span on user's source code
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: byte `193` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix #76869.
Properly note when query stack is being cut off cc #70953 also, i'm not certain whether we should even limit this at all. i don't see the problem with printing the full query stack, apparently it was limited b/c we used to ICE? but we're already printing the full stack to disk since #108714. r? oli-obk
Detect missing fields with default values and suggest `..`
When a struct ctor use has missing fields, if all those missing fields have defaults, suggest `..`:
```
error[E0063]: missing fields `field1` and `field2` in initializer of `S`
--> $DIR/non-exhaustive-ctor.rs:16:13
|
LL | let _ = S { field: () };
| ^ missing `field1` and `field2`
|
help: all remaining fields have default values, you can use those values with `..`
|
LL | let _ = S { field: (), .. };
| ++++
```
ci: use ghcr buildkit image
Misc. `rustc_resolve` cleanups Hopefully this PR should make `rustc_resolve` a bit cleaner. Each commit here stands on its own. I tried to only include changes that are easy to review, and are a clear improvement. (but I'll be happy to revert any changes that turn out to be more controversial than I'd thought) Best viewed with whitespace ignored 😁 (especially [these two commits](https://github.com/rust-lang/rust/pull/135826/files/a93616acf3118ef233027d74e8c636f9b79c342d..ae87d005bc92cbecc47b554e634d1bd3d22e1068?diff=unified&w=1))
Remove test panic from File::open Fixes #135831
…=tgross35 Library: Finalize dyn compatibility renaming Update the Reference link to use the new URL fragment from rust-lang/reference#1666 (this change has finally hit stable). Fixes a FIXME. Follow-up to #130827. Part of #130852.
Rollup of 9 pull requests Successful merges: - #132983 (Edit dangling pointers ) - #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block) - #135557 (Point at invalid utf-8 span on user's source code) - #135596 (Properly note when query stack is being cut off) - #135794 (Detect missing fields with default values and suggest `..`) - #135814 (ci: use ghcr buildkit image) - #135826 (Misc. `rustc_resolve` cleanups) - #135837 (Remove test panic from File::open) - #135856 (Library: Finalize dyn compatibility renaming) r? `@ghost` `@rustbot` modify labels: rollup
Add test for checking used glibc symbols This test checks that we do not use too new glibc symbols in the compiler on x64 GNU Linux, in order not to break our [glibc promises](https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html). One thing that isn't solved in the PR yet is to make sure that this test will only run on `dist` CI, more specifically on the `dist-x86_64-linux` runner, in the opt-dist post-optimization tests (it can fail elsewhere, that doesn't matter). Any suggestions on how to do that are welcome. Fixes: #134037 r? `@jieyouxu`
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 : )