Commit Graph

42834 Commits

Author SHA1 Message Date
bors
251206c27b Auto merge of #135268 - pietroalbini:pa-bump-stage0, r=Mark-Simulacrum
Master bootstrap update

Part of the release process.

r? `@Mark-Simulacrum`
2025-01-09 13:33:16 +00:00
Michael Goulet
39daadc76e Account for identity substituted items in symbol mangling 2025-01-09 13:55:40 +01:00
bors
ec12cd8436 Auto merge of #135279 - matthiaskrgr:rollup-ek2qere, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #135212 (Remove outdated information in the `unreachable_pub` lint description)
 - #135225 (Explicitly build proc macro test with panic=unwind)
 - #135242 (add missing provenance APIs on NonNull)
 - #135247 (Add a list of symbols for stable standard library crates)
 - #135269 (Remove some unnecessary `.into()` calls)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-09 10:50:19 +00:00
Oli Scherer
84c8d4f52d Use option combinators instead of manual if/return 2025-01-09 08:48:46 +00:00
Oli Scherer
8505904dcc Remove the now-useless Result from lit_to_const 2025-01-09 08:48:46 +00:00
Oli Scherer
07fcead073 Always take the Ok path in lit_to_const and produce error constants instead 2025-01-09 08:48:00 +00:00
Oli Scherer
787af97bab Use error constant instead of explicit error handling 2025-01-09 08:48:00 +00:00
Oli Scherer
7833cf7a47 Make lit_to_mir_constant infallible 2025-01-09 08:48:00 +00:00
Matthias Krüger
a1cadeab68
Rollup merge of #135269 - estebank:unneeded-into, r=compiler-errors
Remove some unnecessary `.into()` calls
2025-01-09 09:05:10 +01:00
Matthias Krüger
b593085a9e
Rollup merge of #135247 - tgross35:stdlib-sym-list, r=oli-obk
Add a list of symbols for stable standard library crates

There are a few locations where the crate name is checked against an enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some subset thereof. In most cases when we are looking for any "standard library" crate, all four crates should be treated the same. Change this so the crates are listed in one place, and that list is used wherever a list of `std` crates is needed.

`test` could be considered relevant in some of these cases, but generally treating it separate from the others seems preferable while it is unstable.

There are also a few places that Clippy will be able to use this.
2025-01-09 09:05:09 +01:00
Matthias Krüger
84910fc3cd
Rollup merge of #135225 - erickt:fix-test, r=jieyouxu
Explicitly build proc macro test with panic=unwind

Fuchsia explicitly builds rust and all rust targets with `-C panic=abort` to minimize code generation size. However, when compiling a proc-macro with this setting it can cause a warning to be emitted, which breaks `tests/ui/invalid-compile-flags/crate-type-flag.rs`. This hasn't been a problem in the past for us since we compile our proc macros on host, rather than inside Fuchsia.

This attempts to fix the issue by explicitly requiring that we're using the unwinder when compiling this test to avoid the warning being emitted.

Fixes #135223
2025-01-09 09:05:07 +01:00
Matthias Krüger
a9614a5768
Rollup merge of #135212 - Urgau:unreach_pub-upd-descr, r=petrochenkov
Remove outdated information in the `unreachable_pub` lint description

As far as I understand the `unreachable_pub` lint hasn't had false-positives since it started using "effective visibilities". Let's remove that warning from the lint description.

r? `@petrochenkov`
2025-01-09 09:05:05 +01:00
bors
b6b8361bce Auto merge of #133324 - scottmcm:gvn-aggregate-transmute, r=cjgillot
[mir-opt] GVN some more transmute cases

We already did `Transmute`-then-`PtrToPtr`; this adds the nearly-identical `PtrToPtr`-then-`Transmute`.

It also adds `transmute(Foo(x))` → `transmute(x)`, when `Foo` is a single-field transparent type.  That's useful for things like `NonNull { pointer: p }.as_ptr()`.  It also detects when a `Transmute` is just an identity-for-the-value `PtrCast` between different raw pointer types, to help such things fold with other GVN passes.

Found these as I was looking at <https://github.com/rust-lang/compiler-team/issues/807>-related changes.  This also removes the questionably-useful "turn a transmute into a field projection" part of instsimplify (which I added ages ago without an obvious need for it) since that would just put back the field projections that MCP807 is trying to ban.

r? mir-opt
2025-01-09 08:04:37 +00:00
Matthias Krüger
bbf6363edf
Rollup merge of #134875 - compiler-errors:const-destruct-old-solver, r=lcnr
Implement `const Destruct` in old solver

Self-explanatory. Not totally settled that this is the best structure for built-in trait impls for effect goals in the new solver, but it's almost certainly the simplest.

r? lcnr or re-roll
2025-01-09 06:02:41 +01:00
Matthias Krüger
dd0f586b0a
Rollup merge of #134609 - tbu-:pr_win7_gnu, r=davidtwco
Add new `{x86_64,i686}-win7-windows-gnu` targets

These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.

> ## Tier 3 target policy
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [Major Change Proposal (MCP)][https://forge.rust-lang.org/compiler/mcp.html].
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
>   maintainers") on record to be CCed when issues arise regarding the target.
>   (The mechanism to track and CC such developers may evolve over time.)

This is me, `@tbu-` on github.

> - Targets must use naming consistent with any existing targets; for instance, a
>   target for the same CPU or OS as an existing Rust target should use the same
>   name for that CPU or OS. Targets should normally use the same names and
>   naming conventions as used elsewhere in the broader ecosystem beyond Rust
>   (such as in other toolchains), unless they have a very good reason to
>   diverge. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.
>   - Target names should not introduce undue confusion or ambiguity unless
>     absolutely necessary to maintain ecosystem compatibility. For example, if
>     the name of the target makes people extremely likely to form incorrect
>     beliefs about what it targets, the name should be changed or augmented to
>     disambiguate it.
>   - If possible, use only letters, numbers, dashes and underscores for the name.
>     Periods (`.`) are known to cause issues in Cargo.

Consistent with `{x86_64,i686}-win7-windows-msvc`, see also #118150.

> - Tier 3 targets may have unusual requirements to build or use, but must not
>   create legal issues or impose onerous legal terms for the Rust project or for
>   Rust developers or users.
>   - The target must not introduce license incompatibilities.
>   - Anything added to the Rust repository must be under the standard Rust
>     license (`MIT OR Apache-2.0`).
>   - The target must not cause the Rust tools or libraries built for any other
>     host (even when supporting cross-compilation to the target) to depend
>     on any new dependency less permissive than the Rust licensing policy. This
>     applies whether the dependency is a Rust crate that would require adding
>     new license exceptions (as specified by the `tidy` tool in the
>     rust-lang/rust repository), or whether the dependency is a native library
>     or binary. In other words, the introduction of the target must not cause a
>     user installing or running a version of Rust or the Rust tools to be
>     subject to any new license requirements.
>   - Compiling, linking, and emitting functional binaries, libraries, or other
>     code for the target (whether hosted on the target itself or cross-compiling
>     from another target) must not depend on proprietary (non-FOSS) libraries.
>     Host tools built for the target itself may depend on the ordinary runtime
>     libraries supplied by the platform and commonly used by other applications
>     built for the target, but those libraries must not be required for code
>     generation for the target; cross-compilation to the target must not require
>     such libraries at all. For instance, `rustc` built for the target may
>     depend on a common proprietary C runtime library or console output library,
>     but must not depend on a proprietary code generation library or code
>     optimization library. Rust's license permits such combinations, but the
>     Rust project has no interest in maintaining such combinations within the
>     scope of Rust itself, even at tier 3.
>   - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>     legal/licensing terms include but are *not* limited to: non-disclosure
>     requirements, non-compete requirements, contributor license agreements
>     (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>     requirements conditional on the employer or employment of any particular
>     Rust developers, revocable terms, any requirements that create liability
>     for the Rust project or its developers or users, or any requirements that
>     adversely affect the livelihood or prospects of the Rust project or its
>     developers or users.

AFAICT, it's the same legal situation as the tier 1 `{x86_64,i686}-pc-windows-gnu`.

> - Neither this policy nor any decisions made regarding targets shall create any
>   binding agreement or estoppel by any party. If any member of an approving
>   Rust team serves as one of the maintainers of a target, or has any legal or
>   employment requirement (explicit or implicit) that might affect their
>   decisions regarding a target, they must recuse themselves from any approval
>   decisions regarding the target's tier status, though they may otherwise
>   participate in discussions.
>   - This requirement does not prevent part or all of this policy from being
>     cited in an explicit contract or work agreement (e.g. to implement or
>     maintain support for a target). This requirement exists to ensure that a
>     developer or team responsible for reviewing and approving a target does not
>     face any legal threats or obligations that would prevent them from freely
>     exercising their judgment in such approval, even if such judgment involves
>     subjective matters or goes beyond the letter of these requirements.

Understood.

> - Tier 3 targets should attempt to implement as much of the standard libraries
>   as possible and appropriate (`core` for most targets, `alloc` for targets
>   that can support dynamic memory allocation, `std` for targets with an
>   operating system or equivalent layer of system-provided functionality), but
>   may leave some code unimplemented (either unavailable or stubbed out as
>   appropriate), whether because the target makes it impossible to implement or
>   challenging to implement. The authors of pull requests are not obligated to
>   avoid calling any portions of the standard library on the basis of a tier 3
>   target not implementing those portions.

This target supports the whole libstd surface, since it's essentially reusing all of the x86_64-pc-windows-gnu target. Understood.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target, using cross-compilation if possible. If the target
>   supports running binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

I tried to write some documentation on that.

> - Tier 3 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to maintain the target. In particular,
>   do not post comments (automated or manual) on a PR that derail or suggest a
>   block on the PR based on a tier 3 target. Do not send automated messages or
>   notifications (via any medium, including via ``@`)` to a PR author or others
>   involved with a PR regarding a tier 3 target, unless they have opted into
>   such messages.
>   - Backlinks such as those generated by the issue/PR tracker when linking to
>     an issue or PR are not considered a violation of this policy, within
>     reason. However, such messages (even on a separate repository) must not
>     generate notifications to anyone involved with a PR who has not requested
>     such notifications.

Understood.

> - Patches adding or updating tier 3 targets must not break any existing tier 2
>   or tier 1 target, and must not knowingly break another tier 3 target without
>   approval of either the compiler team or the maintainers of the other tier 3
>   target.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.
> - Tier 3 targets must be able to produce assembly using at least one of
>   rustc's supported backends from any host target. (Having support in a fork
>   of the backend is not sufficient, it must be upstream.)

Understood.

> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
>

Understood.

r? compiler-team
2025-01-09 06:02:40 +01:00
Matthias Krüger
e4e2d9ceb8
Rollup merge of #128110 - veera-sivarajan:bugfix-80173, r=cjgillot
Suggest Replacing Comma with Semicolon in Incorrect Repeat Expressions

Fixes #80173

This PR detects typos in repeat expressions like `["_", 10]` and `vec![String::new(), 10]` and suggests replacing comma with semicolon.

Also, improves code in other place by adding doc comments and making use of a helper function to check if a type implements `Clone`.

References:
1. For `vec![T; N]`: https://doc.rust-lang.org/std/macro.vec.html
2. For `[T; N]`: https://doc.rust-lang.org/std/primitive.array.html
2025-01-09 06:02:39 +01:00
Scott McMurray
b421a56364 Make the aggregate-then-transmute handling more general 2025-01-08 18:46:31 -08:00
Scott McMurray
293f8e8941 Refactor the cast-then-cast cases together, and support transmute-then-transmute 2025-01-08 18:46:30 -08:00
Scott McMurray
03650dd029 Use layout information to detect transparent transmutes 2025-01-08 18:46:30 -08:00
scottmcm
259c425bd4 Apply suggestions from code review
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
2025-01-08 18:46:30 -08:00
Scott McMurray
8dcc676c92 [mir-opt] GVN some more transmute cases
We already did `Transmute`-then-`PtrToPtr`; this adds the nearly-identical `PtrToPtr`-then-`Transmute`.

It also adds `transmute(Foo(x))` → `transmute(x)`, when `Foo` is a single-field transparent type.  That's useful for things like `NonNull { pointer: p }.as_ptr()`.

Found these as I was looking at MCP807-related changes.
2025-01-08 18:46:30 -08:00
dianne
72945beedd Remove special-casing for argument patterns in MIR typeck 2025-01-08 17:59:27 -08:00
bors
e26ff2f908 Auto merge of #135260 - matthiaskrgr:rollup-8irqs72, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #134228 (Exhaustively handle expressions in patterns)
 - #135194 (triagebot: mark tidy changes with a more specific `A-tidy` label)
 - #135222 (Ensure that we don't try to access fields on a non-struct pattern type)
 - #135250 (A couple simple borrowck cleanups)
 - #135252 (Fix release notes link)
 - #135253 (Revert #131365)

Failed merges:

 - #135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-08 21:31:51 +00:00
Trevor Gross
933c4f5a81 Add a list of symbols for stable standard library crates
There are a few locations where the crate name is checked against an
enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some
subset thereof. In most of these cases, all four crates should likely be
treated the same. Change this so the crates are listed in one place, and
that list is used wherever a list of `std` crates is needed.

`test` could be considered relevant in some of these cases, but
generally treating it separate from the others seems preferable while it
is unstable.

There are also a few places that Clippy will be able to use this.
2025-01-08 16:27:31 -05:00
Esteban Küber
eb917ea24d Remove some unnecessary .into() calls 2025-01-08 21:19:28 +00:00
Pietro Albini
2af3ba9a8a
update cfg(bootstrap) 2025-01-08 21:26:39 +01:00
Pietro Albini
4ae92b7adb
update version placeholders 2025-01-08 20:02:18 +01:00
Michael Goulet
c64f859521 Implement const Destruct in old solver 2025-01-08 18:14:58 +00:00
Erick Tryzelaar
49942961a7 Only test proc-macro invalid compile flags with panic=unwind
Fuchsia explicitly builds rust and all rust targets with `-C
panic=abort` to minimize code generation size. However, when compiling a
proc-macro with this setting it can cause a warning to be emitted, which
breaks `tests/ui/invalid-compile-flags/crate-type-flag.rs`. This hasn't
been a problem in the past for us since we compile our proc macros on
host, rather than inside Fuchsia.

This attempts to fix the issue by explicitly requiring that we're using
the unwinder when compiling this test to avoid the warning being
emitted.

Fixes #135223
2025-01-08 18:00:26 +00:00
Matthias Krüger
9ea76e44e5
Rollup merge of #135250 - lqd:simple-cleanups, r=matthewjasper
A couple simple borrowck cleanups

This PR has a couple simple renamings:
- it's been a long time since the mapping from `Location`s to `PointIndex`es was extracted from `RegionElements` into the `DenseLocationMap`, but only the types were renamed at the time. borrowck still refers to this map as `elements`. That's confusing, especially since sometimes we also use the mapping via `LivenessValues`, and makes more sense as `location_map` instead.
- to clarify `LocationTable` is not as general as it sounds, and is only for datalog polonius. In this branch I didn't rename the handful of `location_table` fields and params to `polonius_table`, but can do that to differentiate it even more from `location_map`. I did try it locally and it looks worthwhile, so if you'd prefer I can also push it here. (Or we could even switch these datalog types and fields to even more explicit names)
- to clarify the incomprehensible `AllFacts`, it is renamed to `PoloniusFacts`. These can be referred to as `facts` within the legacy polonius module, but as `polonius_facts` outside of it to make it clear that they're not about NLLs (nor are they about in-tree polonius but that'll be magically fixed when they're removed in the future)

r? `@matthewjasper`
2025-01-08 18:21:02 +01:00
Matthias Krüger
748effd71a
Rollup merge of #135222 - estebank:issue-135209, r=compiler-errors
Ensure that we don't try to access fields on a non-struct pattern type

Fix #135209.
2025-01-08 18:21:02 +01:00
Matthias Krüger
f92a5ed5b4
Rollup merge of #134228 - oli-obk:pat-lit-path, r=compiler-errors
Exhaustively handle expressions in patterns

We currently have this invariant in HIR that a `PatKind::Lit` or a `PatKind::Range` only contains

* `ExprKind::Lit`
* `ExprKind::UnOp(Neg, ExprKind::Lit)`
* `ExprKind::Path`
* `ExprKind::ConstBlock`

So I made `PatKind::Lit` and `PatKind::Range` stop containing `Expr`, and instead created a `PatLit` type whose `kind` enum only contains those variants.

The only place code got more complicated was in clippy, as it couldn't share as much anymore with `Expr` handling

It may be interesting on merging `ExprKind::{Path,Lit,ConstBlock}` in the future and using the same `PatLit` type (under a new name).

Then it should also be easier to eliminate any and all `UnOp(Neg, Lit) | Lit` matching that we have across the compiler. Some day we should fold the negation into the literal itself and just store it on the numeric literals
2025-01-08 18:21:00 +01:00
Michael Goulet
c55eefe8bc Try to explain borrow for tail expr temporary drop order change in 2024 2025-01-08 16:02:44 +00:00
Michael Goulet
4a099b29cd Don't do AccessDepth::Drop for types with no drop impl 2025-01-08 15:58:10 +00:00
Michael Goulet
197f6d8081 Don't create cycles by normalizing opaques defined in the body we're checking 2025-01-08 15:58:10 +00:00
wieDasDing
13c7122df8 remove an extraneous comment
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
2025-01-08 15:58:09 +00:00
Ding Xiang Fei
34edb21f0b apply suggestions on fn name 2025-01-08 15:58:09 +00:00
Ding Xiang Fei
045271cccc run borrowck tests on BIDs and emit tail-expr-drop-order lints for
potential violations
2025-01-08 15:58:09 +00:00
Rémy Rakic
36ea00c20d rename AllFacts to PoloniusFacts
This is another strangely named struct (and associated fields) that is
hard to see was related to datalog polonius.
2025-01-08 13:23:54 +00:00
Rémy Rakic
3a1a621115 rename LocationTable to PoloniusLocationTable
Its original naming hides the fact that it's related to datalog
polonius, and bound to be deleted in the near future.

It also conflicts with the expected name for the actual NLL location
map, and prefixing it with its use will make the differentiation
possible.
2025-01-08 13:08:25 +00:00
bors
6afee111c2 Auto merge of #133858 - dianne:better-blame-constraints-for-static, r=lcnr
`best_blame_constraint`: Blame better constraints when the region graph has cycles from invariance or `'static`

This fixes #132749 by changing which constraint is blamed for region errors in several cases. `best_blame_constraint` had a heuristic that tried to pinpoint the constraint causing an error by filtering out any constraints where the outliving region is unified with the ultimate target region being outlived. However, it used the SCCs of the region graph to do this, which is unreliable; in particular, if the target region is `'static`, or if there are cycles from the presence of invariant types, it was skipping over the constraints it should be blaming. As is the case in that issue, this could lead to confusing diagnostics. The simplest fix seems to work decently, judging by test stderr: this makes `best_blame_constraint` no longer filter constraints by their outliving region's SCC.

There are admittedly some quirks in the test output. In many cases, subdiagnostics that depend on the particular constraint being blamed have either started or stopped being emitted. After starting at this for quite a while, I think anything too fickle about whether it outputs based on the particular constraint being blamed should instead be looking at the constraint path as a whole, similar to what's done for [the placeholder-from-predicate note](https://github.com/rust-lang/rust/compare/master...dianne:rust:better-blame-constraints-for-static#diff-3c0de6462469af483c9ecdf2c4b00cb26192218ef2d5c62a0fde75107a74caaeR506).

Very many tests involving invariant types gained a note pointing out the types' invariance, but in a few cases it was lost. A particularly illustrative example is [tests/ui/lifetimes/copy_modulo_regions.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:better-blame-constraints-for-static?expand=1#diff-96e1f8b29789b3c4ce2f77a5e0fba248829b97ef9d1ce39e7d2b4aa57b2cf4f0); I'd argue the new constraint is a better one to blame, but it lacks the variance diagnostic information that's elsewhere in the constraint path. If desired, I can try making that note check the whole path rather than just the blamed constraint.

The subdiagnostic [`BorrowExplanation::add_object_lifetime_default_note`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/diagnostics/explain_borrow/enum.BorrowExplanation.html#method.add_object_lifetime_default_note) depends on a `Cast` being blamed, so [a special case](364ca7f99c) was necessary to keep it from disappearing from tests specifically testing for it. However, see the FIXME comment in that commit; I think the special case should be removed once that subdiagnostic works properly, but it's nontrivial enough to warrant a separate PR. Incidentally, this removes the note from a test where it was being added erroneously: in [tests/ui/borrowck/two-phase-surprise-no-conflict.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:better-blame-constraints-for-static?expand=1#diff-8cf085af8203677de6575a45458c9e6b03412a927df879412adec7e4f7ff5e14), the object lifetime is explicitly provided and it's not `'static`.
2025-01-08 12:37:54 +00:00
Rémy Rakic
6f1c4177e7 stop calling DenseLocationMap "elements"
"Elements" are `RegionElement`s. The dense location mapping was removed
from the element containers a while ago but didn't rename its use-sites.
Most of the old naming only used the mapping, and are better named
`location_map`.
2025-01-08 11:46:18 +00:00
Martin Nordholts
54ce831db0 rustc_feature: Avoid unsafe std::env::set_var() in UnstableFeatures tests
Avoid unsafe `std::env::set_var()` by allowing tests to inject
`std::env::var("RUSTC_BOOTSTRAP")` with a `env_var_rustc_bootstrap`
parameter.
2025-01-08 11:37:19 +01:00
Oli Scherer
4a8773a3af Rename PatKind::Lit to Expr 2025-01-08 07:34:59 +00:00
Oli Scherer
c9365dd09f Exhaustively handle expressions in patterns 2025-01-08 07:33:46 +00:00
Oli Scherer
5df69191cb Avoid passing a full Pat when only the Span/HirId is used 2025-01-08 07:33:46 +00:00
Oli Scherer
9942b77c5b Avoid passing a full Expr when only the Span is used 2025-01-08 07:33:46 +00:00
Jacob Pratt
485fae594c
Rollup merge of #135219 - matthiaskrgr:simd'nt, r=compiler-errors
warn about broken simd not only on structs but also enums and unions when we didn't opt in to it

addresses https://github.com/rust-lang/rust/issues/135208#issuecomment-2576015186

r? ``@Noratrieb``
2025-01-08 00:52:49 -05:00
Jacob Pratt
57eb95ca6f
Rollup merge of #135203 - RalfJung:arm-soft-float, r=workingjubilee
arm: add unstable soft-float target feature

This has an actual usecase as mentioned [here](https://github.com/rust-lang/rust/issues/116344#issuecomment-2575324988), and with my recent ARM float ABI changes there shouldn't be any soundness concerns any more. We will reject enabling this feature on `hf` targets, but disabling it on non-`hf` targets is entirely fine -- the target feature refers to whether softfloat emulation is used for float instructions, and is independent of the ABI which we set separately via `llvm_floatabi`.

Cc ``@workingjubilee``
2025-01-08 00:52:49 -05:00
Jacob Pratt
45250f367f
Rollup merge of #135184 - biabbas:reserve_18_aarch64, r=workingjubilee
Reserve x18 register for aarch64 wrs vxworks target

Fixes #135166
r? ``@workingjubilee``

Regards,
B I Abbas
2025-01-08 00:52:48 -05:00
Jacob Pratt
808c8f84c3
Rollup merge of #134920 - lqd:polonius-next-episode-6, r=jackh726
Convert typeck constraints in location-sensitive polonius

In this PR, we do a big chunk of the work of localizing regular outlives constraints.

The slightly annoying thing is handling effectful statements: usually the subset graph propagates loans at a single point between regions, and liveness propagates loans between points within a single region, but some statements have effects applied on exit.

This was also a problem before, in datalog polonius terms and Niko's solution at the time, this is about: the mid-point. The idea was to duplicate all MIR locations into two physical points, and orchestrate the effects with that. Somewhat easier to do, but double the CFG.

We've always believed we didn't _need_ midpoints in principle, as we can represent changes on exit as on happening entry to the successor, but there's some difficulty in tracking the position information at sufficient granularity through outlives relation (especially since we also have bidirectional edges and time-traveling now).

Now, that is surely what we should be doing in the future. In the mean time, I infer this from the kind of statement/terminator where an outlives constraint arose. It's not particularly complicated but some explanation will help clarify the code.

Assignments (in their various forms) are the quintessential example of these crossover cases: loans that would flow into the LHS would not be visible on entry to the point but on exit -- so we'll localize these edges to the successor. Let's look at a real-world example, involving invariance for bidirectional edges:

```rust
let mut _1: HashMap<i32, &'7 i32>;
let mut _3: &'9 mut HashMap<i32, &'10 i32>;
...
/* at bb1[3]: */ _3 = &'3 mut _1;
```

Here, typeck expectedly produces 3 outlives constraints today:
1. `'3 -> '9`
2. `'7 -> '10`
3. `'10 -> '7`

And we localize them like so,

1. `'3 -> '9` flows into the LHS and becomes: `3_bb1_3 -> 9_bb1_4`
2. `'7 -> '10` flows into the LHS and becomes: `7_bb1_3 -> 10_bb1_4`
3. `'10 -> '7` flows from the LHS and becomes: `10_bb1_4 -> 7_bb1_3` (time traveling 👌)

---

r? ``@jackh726``

To keep you entertained during the holidays I also threw in a couple of small changes removing cruft in the borrow checker.

We're actually getting there. The next PR will be the last one needed to get end-to-end tests working.
2025-01-08 00:52:46 -05:00
Michael Goulet
11bc805369 Don't allow DispatchFromDyn impls that transmute ZST to non-ZST 2025-01-08 00:45:47 +00:00
Michael Goulet
3c3186148e Don't allow transmuting ZSTs in dispatch_from_dyn impl 2025-01-08 00:28:47 +00:00
Esteban Küber
d44f021904 Add check for missing fields in enum variant pattern 2025-01-08 00:10:16 +00:00
Esteban Küber
5f04f98c9a Ensure that we don't try to access fields on a non-struct pattern type in diagnostic
Fix #135209.
2025-01-07 22:06:58 +00:00
Martin Zacho
66c9a59a14 don't return an Option from try_find_dep_kind 2025-01-07 21:57:00 +01:00
Matthias Krüger
3e12d4d152
Rollup merge of #135149 - compiler-errors:mangle, r=oli-obk
Use a post-monomorphization typing env when mangling components that come from impls

When mangling associated methods of impls, we were previously using the wrong param-env. Instead of using a fully monomorphized param-env like we usually do in codegen, we were taking the post-analysis param-env, and treating it as an early binder to *re-substitute* the impl args. I've pointed out the problematic old code in an inline comment.

This would give us param-envs with possibly trivial predicates that would prevent normalization via param-env shadowing.

In the example test linked below, `tests/ui/symbol-names/normalize-in-param-env.rs`, this happens when we mangle the impl `impl<P: Point2> MyFrom<P::S> for P` with the substitution `P = Vec2`. Because the where clause of the impl is `P: Point2`, which elaborates to `[P: Point2, P: Point, <P as Point>::S projects-to <P as Point2>::S2]` and the fact that `impl Point2 for Vec2` normalizes `Vec2::S2` to `Vec2::S`, this causes a cycle.

The proper fix here is to use a fully monomorphized param-env for the case where the impl is properly substituted.

Fixes #135143

While #134081 uncovered this bug for legacy symbol mangling, it was preexisting for v0 symbol mangling. This PR fixes both. The test requires a "hack" because we strip the args of the instance we're printing for legacy symbol mangling except for drop glue, so we box a closure to ensure we generate drop glue.

r? oli-obk
2025-01-07 21:39:41 +01:00
Matthias Krüger
a20d0d5a5c
Rollup merge of #134989 - max-niederman:guard-patterns-hir, r=oli-obk
Lower Guard Patterns to HIR.

Implements lowering of [guard patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see the [tracking issue](#129967)) to HIR.
2025-01-07 21:39:40 +01:00
Matthias Krüger
c371a94e78
Rollup merge of #134745 - compiler-errors:better-arg-span-in-typeck, r=BoxyUwU
Normalize each signature input/output in `typeck_with_fallback` with its own span

Applies the same hack as #106582 but to the args in typeck. Greatly improves normalization error spans from a signature.
2025-01-07 21:39:39 +01:00
Matthias Krüger
191fb23940
Rollup merge of #133810 - lcnr:remove-verify_bound, r=compiler-errors
remove unnecessary `eval_verify_bound`

This does not impact any tests. I feel like any cases where this could useful should instead be fixed by a general improvement to `eval_verify_bound` to avoid having to promote this `TypeTest` in the first place 🤔

r? types cc ``@nikomatsakis``
2025-01-07 21:39:38 +01:00
Matthias Krüger
b9d6e9e73f warn about broken simd not only on structs but also enums and unions when we didn't opt in to it 2025-01-07 21:36:37 +01:00
Urgau
56cba09d1e Remove outdated information in the unreachable_pub lint description 2025-01-07 19:07:06 +01:00
Ralf Jung
427abb69bf arm: add unstable soft-float target feature 2025-01-07 16:13:43 +01:00
Mara Bos
585c9765a2 Update tests. 2025-01-07 16:04:14 +01:00
Mara Bos
e7bd340ba4 Switch missing_abi lint to warn-by-default. 2025-01-07 15:48:19 +01:00
Guillaume Gomez
225ffebc0a
Rollup merge of #135199 - joshtriplett:unnecessary-to-string, r=lqd
Eliminate an unnecessary `Symbol::to_string`; use `as_str`
2025-01-07 15:30:28 +01:00
Guillaume Gomez
ec266207cb
Rollup merge of #135198 - joshtriplett:str-is-a-type, r=jieyouxu
Avoid naming variables `str`

This renames variables named `str` to other names, to make sure `str`
always refers to a type.

It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
2025-01-07 15:30:28 +01:00
Guillaume Gomez
a33da79fa9
Rollup merge of #135182 - scottmcm:box-deref-via-transmute, r=oli-obk
Transmute from NonNull to pointer when elaborating a box deref (MCP807)

Since per https://github.com/rust-lang/compiler-team/issues/807 we have to stop projecting into `NonNull`.

cc https://github.com/rust-lang/rust/issues/133652
2025-01-07 15:30:25 +01:00
Guillaume Gomez
020d8758f4
Rollup merge of #135177 - maurer:rename-module, r=nikic
llvm: Ignore error value that is always false

See llvm/llvm-project#121851

For LLVM 20+, this function (`renameModuleForThinLTO`) has no return value. For prior versions of LLVM, this never failed, but had a signature which allowed an error value people were handling.

`@rustbot` label: +llvm-main
r? `@nikic`

Wait a moment before approving while the llvm-main infrastructure picks it up.
2025-01-07 15:30:25 +01:00
Josh Triplett
bb6bbfa13f Avoid naming variables str
This renames variables named `str` to other names, to make sure `str`
always refers to a type.

It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
2025-01-07 14:30:02 +02:00
Josh Triplett
7cc99a864a Eliminate an unnecessary Symbol::to_string; use as_str 2025-01-07 14:24:47 +02:00
bors
fb546ee09b Auto merge of #135173 - pietroalbini:pa-fix-rvp, r=workingjubilee
Avoid replacing the definition of `CURRENT_RUSTC_VERSION`

Before this PR, replace-version-placeholder hardcoded the path defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor moved the file defining it without changing the hardcoded path, the tool started replacing the constant itself with the version number.

To avoid this from happening in the future, this changes the definition of the constant to avoid the tool from ever matching it.

r? `@workingjubilee`
2025-01-07 07:21:09 +00:00
B I Mohammed Abbas
af15e048b2 Reserve x18 register for aarch64 wrs vxworks target 2025-01-07 09:18:31 +05:30
Jacob Pratt
44808ae798
Rollup merge of #135126 - klensy:deprecated-and-do-nothing, r=jieyouxu
mark deprecated option as deprecated in rustc_session to remove copypasta and small refactor

This marks deprecated options as deprecated via flag in options table in rustc_session, which removes copypasted deprecation text from rustc_driver_impl.

This also adds warning for deprecated `-C ar` option, which didn't emitted any warnings before.
Makes `inline_threshold` `[UNTRACKED]`, as it do nothing.
Adds few tests.

See individual commits.
2025-01-06 22:04:17 -05:00
Jacob Pratt
8b54f951e5
Rollup merge of #135090 - compiler-errors:invalid-tuple-ctor-projection, r=lqd,jieyouxu
Suggest to replace tuple constructor through projection

See the code example. when `Self::Assoc` normalizes to a struct that has a tuple constructor, you cannot construct the type via `Self::Assoc(field, field)`. Instead, suggest to replace it with the correct named struct.

Fixes #120871
2025-01-06 22:04:15 -05:00
Jacob Pratt
3deb5c289e
Rollup merge of #134744 - compiler-errors:transmute-non-wf, r=lcnr
Don't ice on bad transmute in typeck in new solver

Old trait solver ends up getting its infcx tainted because we try to normalize the type, but the new trait solver doesn't. This means we try to compute the stalled transmute obligations, which tries to normalize a type an ICEs. Let's make this a delayed bug.

r? lcnr
2025-01-06 22:04:15 -05:00
Jacob Pratt
b642740e4f
Rollup merge of #132345 - compiler-errors:fx-diag, r=lcnr
Improve diagnostics for `HostEffectPredicate` in the new solver

Adds derived cause for host effect predicates. Some diagnostics regress, but that's connected to the fact that our predicate visitor doesn't play well with aliases just yet.
2025-01-06 22:04:13 -05:00
Jacob Pratt
4e4a93c2dd
Rollup merge of #131830 - hoodmane:emscripten-wasm-eh, r=workingjubilee
Add support for wasm exception handling to Emscripten target

This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
2025-01-06 22:04:13 -05:00
Scott McMurray
ad5f912d96 Transmute from NonNull to pointer when elaborating a box deref (MCP807) 2025-01-06 18:43:40 -08:00
Matthew Maurer
fc32dd49cb llvm: Ignore error value that is always false
See llvm/llvm-project#121851

For LLVM 20+, this function (`renameModuleForThinLTO`) has no return
value. For prior versions of LLVM, this never failed, but had a
signature which allowed an error value people were handling.
2025-01-07 01:02:22 +00:00
dianne
fe8b12f8cf only avoid blaming assignments from argument patterns 2025-01-06 16:12:11 -08:00
dianne
1b2281a493 point out unblamed constraints from Copy/Sized bounds in region errors 2025-01-06 16:12:11 -08:00
dianne
2c5815b285 make outlives constraints from pointer comparisons less boring 2025-01-06 16:12:11 -08:00
dianne
10061b3a4f make outlives constraints from generic arguments less boring 2025-01-06 16:12:11 -08:00
dianne
6421d4cf80 best_blame_constraint: prioritize blaming interesting-seeming constraints 2025-01-06 16:12:11 -08:00
dianne
45b2ae935d remove the unused ConstraintCategory::ClosureBounds 2025-01-06 16:12:11 -08:00
dianne
50222dba2e best_blame_constraint: avoid blaming assignments without user-provided types 2025-01-06 16:12:11 -08:00
dianne
31e4d8175a best_blame_constraint: avoid blaming constraints from MIR generated by desugaring 2025-01-06 16:12:11 -08:00
dianne
2864906fce best_blame_constraint: add a special case to recover object lifetime default notes 2025-01-06 16:12:04 -08:00
dianne
ac922245f0 best_blame_constraint: don't filter constraints by sup SCC
The SCCs of the region graph are not a reliable heuristic to use for blaming an interesting
constraint for diagnostics. For region errors, if the outlived region is `'static`, or the involved
types are invariant in their lifetiems, there will be cycles in the constraint graph containing both
the target region and the most interesting constraints to blame. To get better diagnostics in these
cases, this commit removes that heuristic.
2025-01-06 16:08:29 -08:00
dianne
2249232ad8 further clean up best_blame_constraint
This gets rid of `categorized_path`, as it was redundant given the `OutlivesConstraint`s in `path`
already have a category field.
2025-01-06 15:53:33 -08:00
dianne
aa8d5bff4c cleanup: remove ExtraConstraintInfo
`ExtraConstraintInfo` was used only for a single subdiagnostic, so this moves the logic for that
to its own function and eliminates the indirection. In order to do so cleanly, this also changes
the arguments to `BorrowExplanation::add_explanation_to_diagnostic`, which happens to simplify its
call sites.
2025-01-06 15:53:30 -08:00
Pietro Albini
80cdaeac3d
avoid replacing the definition of CURRENT_RUSTC_VERSION
Before this commit, replace-version-placeholder hardcoded the path
defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor
moved the file defining it without changing the hardcoded path, the tool
started replacing the constant itself with the version number.

To avoid this from happening in the future, this changes the definition
of the constant to avoid the tool from ever matching it.
2025-01-06 21:53:48 +01:00
Matthias Krüger
68791efa29
Rollup merge of #134951 - compiler-errors:double-trait-err-msg, r=davidtwco
Suppress host effect predicates if underlying trait doesn't hold

Don't report two errors for when the (`HostEffectPredicate`) `T: const Trait` isn't implemented because (`TraitPredicate`) `T: Trait` doesn't even hold.
2025-01-06 20:59:33 +01:00
Matthias Krüger
44c6e83b49
Rollup merge of #134771 - compiler-errors:const-arg-has-type-err, r=lcnr
Report correct `SelectionError` for `ConstArgHasType` in new solver fulfill

r? ``@BoxyUwU``
2025-01-06 20:59:32 +01:00
Matthias Krüger
49b05ed7c1
Rollup merge of #134742 - compiler-errors:post-borrowck-analysis, r=lcnr
Use `PostBorrowckAnalysis` in `check_coroutine_obligations`

This currently errors with:

```
error: concrete type differs from previous defining opaque type use
  --> tests/ui/coroutine/issue-52304.rs:10:21
   |
10 | pub fn example() -> impl Coroutine {
   |                     ^^^^^^^^^^^^^^ expected `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'{erased} i32 return_ty=() witness={example::{closure#0}}}`, got `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'static i32 return_ty=() witness={example::{closure#0}}}`
   |
   = note: previous use here
```

This is because we end up redefining the opaque in `check_coroutine_obligations` but with the `yield_ty = &'erased i32` from hir typeck, which causes the *equality* check for opaques to fail.

The coroutine obligtions in question (when `-Znext-solver` is enabled) are:

```
Binder { value: TraitPredicate(<Opaque(DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), []) as std::marker::Sized>, polarity:Positive), bound_vars: [] }

Binder { value: AliasRelate(Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. })), Equate, Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()]))), bound_vars: [] }

Binder { value: AliasRelate(Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()])), Subtype, Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. }))), bound_vars: [] }
```

Ignoring the fact that we end up stalling some really dumb obligations here (lol), I think it makes more sense for us to be using post borrowck analysis for this check anyways.

r? lcnr
2025-01-06 20:59:31 +01:00
Michael Goulet
304ccf45d1 Suggest to replace tuple constructor through projection 2025-01-06 18:04:33 +00:00
Michael Goulet
ebdf19a8bb Recurse on GAT where clauses in fulfillment error proof tree visitor 2025-01-06 17:58:42 +00:00
Michael Goulet
5a566005c1 Normalize each signature input/output in typeck_with_fallback with its own span 2025-01-06 17:58:30 +00:00
Michael Goulet
96285bde38 Don't ice on bad transmute in typeck in new solver 2025-01-06 17:56:16 +00:00
Michael Goulet
2be9ffc1af Add derived causes for host effect predicates 2025-01-06 17:49:46 +00:00
Tobias Bucher
8630234ebc Add new {x86_64,i686}-win7-windows-gnu targets
These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.
2025-01-06 15:32:17 +01:00
Rémy Rakic
fc7ee238d1 address review comments
push constraint creation to where the statement/terminator info is gathered
2025-01-06 14:20:54 +00:00
klensy
37f26311eb add deprecated and do nothing flag to options table
inline_threshold mark deprecated

no-stack-check

print deprecation message for -Car too

inline_threshold deprecated and do nothing: make in untracked

make OptionDesc struct from tuple
2025-01-06 15:38:02 +03:00
Hood Chatham
49c74234a7 Add support for wasm exception handling to Emscripten target
Gated behind an unstable `-Z emscripten-wasm-eh` flag
2025-01-06 10:29:54 +01:00
Martin Zacho
38e10e5619 improve diagnostics for const eval query overflow 2025-01-06 09:43:05 +01:00
bors
13738b0abe Auto merge of #135151 - matthiaskrgr:rollup-2vy1hwl, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #135111 (Add doc aliases for `libm` and IEEE names)
 - #135129 (triagebot: label `src/doc/rustc-dev-guide` changes with `A-rustc-dev-guide`)
 - #135132 (dev guide ping group and set adhoc reviewers to compiler)
 - #135145 (Mention `unnameable_types` in `unreachable_pub` documentation.)
 - #135147 (A few borrowck tweaks to improve 2024 edition migration lints)
 - #135150 (move footnote to ordinary comment)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-06 08:08:13 +00:00
Martin Zacho
83853ccdc3 depth limit eval_to_const_value_raw 2025-01-06 08:54:27 +01:00
Matthias Krüger
c5c05c2528
Rollup merge of #135150 - lcnr:unconstrained-lts-comment, r=oli-obk
move footnote to ordinary comment

cc #135057
2025-01-06 08:09:07 +01:00
Matthias Krüger
ee6914a45b
Rollup merge of #135147 - compiler-errors:borrowck-tweaks, r=chenyukang
A few borrowck tweaks to improve 2024 edition migration lints

See first two commits' changes to test outputs. Test coverage in this area is kinda weak, but I think it affects more cases than this (like the craters that will begin to trigger the `tail_expr_drop_order` tests in #134523).

Third commit is a drive-by change that removes a deref hack from `UseSpans` which doesn't really improve diagnostics much.
2025-01-06 08:09:06 +01:00
Matthias Krüger
b561659e43
Rollup merge of #135145 - kpreid:unnameable, r=compiler-errors
Mention `unnameable_types` in `unreachable_pub` documentation.

This link makes sense because someone who wishes to avoid unusable `pub` is likely, but not guaranteed, to be interested in avoiding unnameable types.

Also fixed some grammar problems I noticed in the area.

Fixes #116604.

r? Urgau
2025-01-06 08:09:05 +01:00
lcnr
ae6a3313cf footnote to ordinary comment 2025-01-06 07:37:52 +01:00
Michael Goulet
86d8b79d0d Use a post-monomorphization typing env when mangling components that come from impls 2025-01-06 06:11:15 +00:00
bors
fd98df8f14 Auto merge of #135085 - knickish:m68k_unknown_none, r=workingjubilee
add m68k-unknown-none-elf target

r? `@workingjubilee`

The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.

I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
2025-01-06 05:23:55 +00:00
Michael Goulet
339902908e Remove CallKind::Deref hack from UseSpans
It's not really necessary
2025-01-06 03:55:19 +00:00
Michael Goulet
cd65cd27db Improve find_self_call with reborrowed receiver 2025-01-06 03:17:04 +00:00
Michael Goulet
3560a2b399 Improve span when temporary receiver is dropped in edition 2024 2025-01-06 03:14:04 +00:00
bors
56f9e6f935 Auto merge of #135140 - jhpratt:rollup-pn2gi84, r=jhpratt
Rollup of 3 pull requests

Successful merges:

 - #135115 (cg_llvm: Use constants for DWARF opcodes, instead of FFI calls)
 - #135118 (Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`)
 - #135121 (Mark `slice::reverse` unstably const)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-06 02:30:55 +00:00
Kevin Reid
2a96478dd8 Mention unnameable_types in unreachable_pub documentation.
This link makes sense because someone who wishes to avoid unusable `pub`
is likely, but not guaranteed, to be interested in avoiding unnameable
types.

Also fixed some grammar problems I noticed in the area.

Fixes #116604.
2025-01-05 17:13:33 -08:00
Jacob Pratt
b9f971a52c
Rollup merge of #135115 - Zalathar:dwarf-const, r=workingjubilee
cg_llvm: Use constants for DWARF opcodes, instead of FFI calls

Split off from #134009 to incorporate feedback from https://github.com/rust-lang/rust/pull/134009#discussion_r1903133906.

Most of the constant values now come from gimli, which is already a compiler dependency.

I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens.

r? workingjubilee
2025-01-05 18:35:04 -05:00
bors
feb32c6546 Auto merge of #134794 - RalfJung:abi-required-target-features, r=workingjubilee
Add a notion of "some ABIs require certain target features"

I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI.  This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.

We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.

For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)

As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.

r? `@workingjubilee`
2025-01-05 23:21:06 +00:00
bjorn3
a94e2d513b Merge commit '918acafef682d0d0ca30b47de4768210417ff362' into sync_cg_clif-2025-01-05 2025-01-05 15:44:46 +00:00
Zalathar
f50721ebad Explain why the DW_TAG_* constants remain as-is for now 2025-01-05 22:16:49 +11:00
Zalathar
1b62645418 Use constants for DWARF opcodes, instead of FFI calls 2025-01-05 22:16:25 +11:00
Zalathar
e267106104 Use gimli to get the values of DWARF constants needed by codegen
The `gimli` crate is already a dependency of `thorin-dwp`, which is already a
dependency of `rustc_codegen_ssa`.
2025-01-05 22:07:48 +11:00
Ralf Jung
2e64b5352b add dedicated type for ABI target feature constraints 2025-01-05 10:46:30 +01:00
bors
7270e73b62 Auto merge of #135074 - wzssyqa:mips-mti, r=oli-obk
Target: Add mips mti baremetal support

Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.

We support both big endian and little endian flavor:
  mips-mti-none-elf
  mipsel-mti-none-elf
2025-01-05 07:01:38 +00:00
kirk
ff7f818fc7 change to static relocation model 2025-01-05 05:04:34 +00:00
bors
3dc3c524f7 Auto merge of #133990 - Walnut356:static_const, r=workingjubilee
[Debuginfo] Force enum `DISCR_*` to `static const u64` to allow for inspection via LLDB

see [here](https://rust-lang.zulipchat.com/#narrow/channel/317568-t-compiler.2Fwg-debugging/topic/Revamping.20Debuginfo/near/486614878) for more info.

This change mainly helps `*-msvc` debugged with LLDB. Currently, LLDB cannot inspect `static` struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all .

LLDB *can* inspect `static const` values (though for whatever reason, non-enum/non-u64 consts don't work).

This change adds the `LLVMRustDIBuilderCreateQualifiedType` to the rust FFI layer to wrap the discr type with a `const` modifier, as well as forcing all generated integer enum `DISCR_*` values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The `tag` also still properly reflects the discriminant type, so no information is lost.
2025-01-04 23:56:29 +00:00
bors
1891c28669 Auto merge of #135101 - workingjubilee:rollup-owp3czl, r=workingjubilee
Rollup of 6 pull requests

Successful merges:

 - #135046 (turn rustc_box into an intrinsic)
 - #135061 (crashes: add latest batch of tests)
 - #135070 (std: sync to dep versions of backtrace)
 - #135088 (Force code generation in assembly generation smoke-tests)
 - #135091 (Bump backtrace to 0.3.75)
 - #135094 (bootstrap: If dir_is_empty fails, show the non-existent directory path)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-04 21:11:28 +00:00
knickish
139ca10f65
Apply suggestions from workingjubilee's code review
Co-authored-by: Jubilee <workingjubilee@gmail.com>
2025-01-04 12:52:19 -06:00
Jubilee
7cf3b96a83
Rollup merge of #135046 - RalfJung:rustc_box_intrinsic, r=compiler-errors
turn rustc_box into an intrinsic

I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
2025-01-04 07:57:33 -08:00
bors
2a8af4f7c8 Auto merge of #133955 - bjorn3:cc_pass_arch_only, r=ChrisDenton
Pass the arch rather than full target name to windows_registry::find_tool

The full target name can be anything with custom target specs. Passing just the arch wasn't possible before cc 1.2, but is now thanks to https://github.com/rust-lang/cc-rs/pull/1285.

try-job: i686-msvc
2025-01-04 15:42:31 +00:00
bors
fd127a3a84 Auto merge of #135031 - RalfJung:intrinsics-without-body, r=oli-obk
rustc_intrinsic: support functions without body

We synthesize a HIR body `loop {}` but such bodyless intrinsics.

Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.

I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)

r? `@oli-obk`
2025-01-04 12:50:38 +00:00
Ralf Jung
3cd3649c6c rustc_intrinsic: support functions without body; they are implicitly marked as must-be-overridden 2025-01-04 11:41:51 +01:00
Ralf Jung
be65012aa3 turn hir::ItemKind::Fn into a named-field variant 2025-01-04 11:35:31 +01:00
bors
f17cf744f5 Auto merge of #135095 - matthiaskrgr:rollup-tmgxckq, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #133964 (core: implement `bool::select_unpredictable`)
 - #135001 (Allow using self-contained LLD in bootstrap)
 - #135055 (Report impl method has stricter requirements even when RPITIT inference gets in the way)
 - #135064 (const-in-pattern: test that the PartialEq impl does not need to be const)
 - #135066 (bootstrap: support `./x check run-make-support`)
 - #135069 (remove unused function params)
 - #135084 (Update carrying_mul_add test to tolerate `nuw`)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-04 10:02:59 +00:00
Matthias Krüger
725b799478
Rollup merge of #135069 - matthiaskrgr:param_rec_usage, r=jieyouxu
remove unused function params
2025-01-04 09:54:39 +01:00
Matthias Krüger
966a5be559
Rollup merge of #135064 - RalfJung:const-in-pat-partial-eq-not-const, r=compiler-errors
const-in-pattern: test that the PartialEq impl does not need to be const

Fixes https://github.com/rust-lang/rust/issues/119398 by adding a test.

`@compiler-errors`  is there some place in the code where we could add a comment saying "as a backcompat hack, here we only require `PartialEq` and not `const PartialEq`"?

r? `@compiler-errors`
2025-01-04 09:54:38 +01:00
Matthias Krüger
b0b54f2f8b
Rollup merge of #135055 - compiler-errors:rpitit-infer-in-stricter-impl, r=estebank
Report impl method has stricter requirements even when RPITIT inference gets in the way

See the comment I added in the code. Fixes #122506.
2025-01-04 09:54:38 +01:00
bors
49761b073c Auto merge of #135067 - ChrisDenton:cc, r=jieyouxu
Bump cc in the compiler

Changelog:

- Regenerate target info ([#1342](https://github.com/rust-lang/cc-rs/pull/1342))
- Allow using Visual Studio target names in `find_tool` ([#1335](https://github.com/rust-lang/cc-rs/pull/1335))
- Fix `is_flag_supported` on msvc ([#1336](https://github.com/rust-lang/cc-rs/pull/1336))
2025-01-04 07:18:33 +00:00
bors
7349f6b503 Auto merge of #135057 - compiler-errors:project-unconstrained, r=oli-obk
Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params

It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`.

The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query.

I think this is a bit less invasive of an approach compared to #127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did.

Fixes #123141
Fixes #125874
Fixes #126942
Fixes #127804
Fixes #130967

r? oli-obk
2025-01-04 04:35:55 +00:00
Matthias Krüger
12cc9b4b6f
Rollup merge of #135044 - compiler-errors:better-infer-suggestions-in-const, r=oli-obk
Improve infer (`_`) suggestions in `const`s and `static`s

Fixes https://github.com/rust-lang/rust/issues/135010.

This PR does a few things to (imo) greatly improve the error message when users write something like `static FOO: [i32; _] = [1, 2, 3]`.

Firstly, it adapts the recovery code for when we encounter `_` in a const/static to work a bit more like `fn foo() -> _`, and removes the somewhat redundant query `diagnostic_only_typeck`.

Secondly, it changes the lowering for `[T; _]` to always lower under the `feature(generic_arg_infer)` logic to `ConstArgKind::Infer`. We still issue the feature error, so it's not doing anything *observable* on the good path, but it does mean that we no longer erroneously interpret `[T; _]`'s array length as a `_` **wildcard expression** (à la destructuring assignment, like `(_, y) = expr`).

Lastly it makes the suggestions verbose and fixes (well, suppresses) a bug with stashing and suggestions.

r? oli-obk
2025-01-03 22:12:45 +01:00
Matthias Krüger
cdfe3d7f4a
Rollup merge of #135007 - compiler-errors:outlives-tweaks, r=oli-obk
Some type-outlives computation tweaks

Some tweaks that I wrote when investigating https://github.com/rust-lang/rust/issues/135006.

The only commit that's probably interesting here is f3646748cd (the first commit). For some reason it was concerned with filtering out param-env outlives clauses when they matched item-bound outlives clauses. However, if you look at the rest of the control flow for that function, not filtering out those bounds doesn't actually affect the behavior materially.
2025-01-03 22:12:43 +01:00
Matthias Krüger
4cd289550f
Rollup merge of #133420 - thesummer:rtems-unwind, r=workingjubilee
Switch rtems target to panic unwind

Switch the RTEMS target to `panic_unwind`.

Relates to https://github.com/rust-lang/backtrace-rs/pull/682
2025-01-03 22:12:41 +01:00
kirk
2287491480 add m68k-unknown-none-elf target 2025-01-03 21:09:11 +00:00
Michael Goulet
e4193e2de8 Do not ICE when encountering predicates from other items in method error reporting 2025-01-03 19:39:39 +00:00
bors
3f43b1a636 Auto merge of #135034 - Noratrieb:strip-correctly, r=jieyouxu
Pass objcopy args for stripping on OSX

When `-Cstrip` was changed in #131405 to use the bundled rust-objcopy instead of /usr/bin/strip on OSX, strip-like arguments were preserved.

But strip and objcopy are, while being the same binary, different, they have different defaults depending on which binary they are. Notably, strip strips everything by default, and objcopy doesn't strip anything by default.

Additionally, `-S` actually means `--strip-all`, so debuginfo stripped everything and symbols didn't strip anything.

We now correctly pass `--strip-debug` and `--strip-all`.

fixes #135028

try-job: aarch64-apple
try-job: dist-aarch64-apple
2025-01-03 17:20:39 +00:00
Ralf Jung
b806dccdc4 const-in-pattern: test that the PartialEq impl does not need to be const 2025-01-03 16:08:29 +01:00
YunQiang Su
5a0ce36232 Target: Add mips mti baremetal support
Do the same thing as gcc, which use the vendor `mti` to mark
the toolchain as MIPS32r2 default.

We support both big endian and little endian flavor:
  mips-mti-none-elf
  mipsel-mti-none-elf
2025-01-03 22:23:49 +08:00
Matthias Krüger
e839d05e11 remove unused function params 2025-01-03 13:30:26 +01:00
Chris Denton
cfe61320b8
Bump cc in the compiler 2025-01-03 11:51:13 +00:00
Ralf Jung
ac9cb908ac turn rustc_box into an intrinsic 2025-01-03 12:01:31 +01:00
Matthias Krüger
0053aa4e9d
Rollup merge of #135049 - cramertj:rmunused, r=compiler-errors
Remove unused fields from RepeatElementCopy obligation
2025-01-03 07:57:27 +01:00
Matthias Krüger
e0f4dc955a
Rollup merge of #135042 - lukas-code:taint-dyn-incompat, r=compiler-errors
taint fcx on selection errors during unsizing

With `feature(dyn_compatible_for_dispatch)` we only check for dyn-compatibility by checking the `T: Unsize<dyn Trait>` predicate during the unsizing coercions checks. If the predicate doesn't hold, we emit an error, but pretend the coercion succeeded to prevent further errors. To prevent const eval from attempting to actually perform this coercion, we need to taint the fcx after reporting the trait errors in the coercion check.

fixes https://github.com/rust-lang/rust/issues/135021
fixes https://github.com/rust-lang/rust/issues/130521
2025-01-03 07:57:26 +01:00
Matthias Krüger
8439ae7422
Rollup merge of #131729 - Urgau:check-cfg-test-userspace, r=petrochenkov
Make the `test` cfg a userspace check-cfg

This PR implements MCP https://github.com/rust-lang/compiler-team/issues/785, which makes the `test` cfg a "userspace" check-cfg, i.e. no longer included in the well known cfg list.

Things to do:

- [x] Accept the MCP (https://github.com/rust-lang/compiler-team/issues/785#issuecomment-2424121886)
- [x] Mark `test` in Cargo (https://github.com/rust-lang/cargo/pull/14963)

`@rustbot` labels +S-waiting-on-MCP +F-check_cfg
r? `@petrochenkov`
2025-01-03 07:57:24 +01:00
Michael Goulet
7143ef6550 Also in the new solver 2025-01-03 05:22:14 +00:00
Michael Goulet
2d602ea793 Do not project when there are unconstrained impl params 2025-01-03 05:01:14 +00:00
Michael Goulet
c29838843b Report impl has stricter requirements even when RPITIT inference gets in the way 2025-01-03 02:45:29 +00:00
Michael Goulet
0fd64efa2f Fix macro shenanigans 2025-01-02 23:39:17 +00:00
Michael Goulet
7601adb4a0 Make suggestion verbose and tweak error message 2025-01-02 23:39:17 +00:00
Michael Goulet
8e344ae127 Suppress type param suggestion if encountering invalid const infer 2025-01-02 23:39:16 +00:00
Michael Goulet
6885ff4a7b Unconditionally lower generic_arg_infer 2025-01-02 23:39:16 +00:00
Michael Goulet
b85a91fc59 More refined spans for placeholder error in const/static 2025-01-02 23:39:16 +00:00
Michael Goulet
c529fe0475 Remove diagnostic_only_typeck and fix placeholder suggestion for const/static 2025-01-02 23:39:16 +00:00
Michael Goulet
c5d4996404 nit: Make get_infer_ret_ty name more consistent with is_suggestable_infer_ty 2025-01-02 23:39:16 +00:00
Taylor Cramer
9281be94b5 Remove unused fields from RepeatElementCopy obligation 2025-01-02 14:46:36 -08:00
Noratrieb
4da3aedb5e Pass objcopy args for stripping on OSX
When `-Cstrip` was changed to use the bundled rust-objcopy instead of
/usr/bin/strip on OSX, strip-like arguments were preserved.

But strip and objcopy are, while being the same binary, different, they
have different defaults depending on which binary they are.
Notably, strip strips everything by default, and objcopy doesn't strip
anything by default.

Additionally, `-S` actually means `--strip-all`, so debuginfo stripped
everything and symbols didn't strip anything.

We now correctly pass `--strip-debug` and `--strip-all`.
2025-01-02 22:17:39 +01:00
Lukas Markeffsky
93bb639ad6 taint fcx on selection errors during unsizing 2025-01-02 19:16:00 +01:00
Urgau
e8a4792b3e Make the test cfg a "userspace" check-cfg 2025-01-02 16:49:55 +01:00
Flakebi
56bf673f0a
Remove range-metadata amdgpu workaround
Range metadata was disabled for amdgpu due to a backend bug. I did not
encounter any problems when removing the workaround to enable range
metadata (tried compiling `core` and `alloc`), so I assume this has
been fixed in LLVM in the last years.

Remove the workaround to re-enable range metadata.
2025-01-02 15:45:04 +01:00
Michael Goulet
dd210eca43 Simplify declared_generic_bounds_from_env 2025-01-02 01:30:55 +00:00
Michael Goulet
2a373d7dd3 Make it clearer that the only infers we expect to see when processing outlives are regions 2025-01-02 00:48:06 +00:00
Michael Goulet
f3646748cd Remove hack for filtering out param-env outlives that match item-bound outlives 2025-01-02 00:48:06 +00:00
bors
504f4f5275 Auto merge of #130060 - EnzymeAD:enzyme-cg-llvm, r=oli-obk
Autodiff Upstreaming - rustc_codegen_llvm changes

Now that the autodiff/Enzyme backend is merged, this is an upstream PR for the `rustc_codegen_llvm` changes.
It also includes small changes to three files under `compiler/rustc_ast`, which overlap with my frontend PR (https://github.com/rust-lang/rust/pull/129458).
Here I only include minimal definitions of structs and enums to be able to build this backend code.
The same goes for minimal changes to `compiler/rustc_codegen_ssa`, the majority of changes there will be in another PR, once either this or the frontend gets merged.

We currently have 68 files left to merge, 19 in the frontend PR, 21 (+3 from the frontend) in this PR, and then ~30 in the middle-end.

This PR is large because it includes two of my three large files (~800 loc each). I could also first only upstream enzyme_ffi.rs, but I think people might want to see some use of these bindings in the same PR?

To already highlight the things which reviewers might want to discuss:

1) `enzyme_ffi.rs`: I do have a fallback module to make sure that we don't link rustc against Enzyme when we build rustc without autodiff support.

2) `add_panic_msg_to_global` was a pain to write and I currently can't even use it. Enzyme writes gradients into shadow memory. Pass in one float scalar? We'll allocate and return an extra float telling you how this float affected the output. Pass in a slice of floats? We'll let you allocate the vector and pass in a mutable reference to a float slice, we'll then write the gradient into that slice. It should be at least as large as your original slice, so we check that and panic if not. Currently we panic silently, but I already generate a nicer panic message with this function. I just don't know how to print it to the user. yet. I discussed this with a few rustc devs and the best we could come up with (for now), was to look for mangled panic calls in the IR and pick one, which works surprisingly reliably. If someone knows a good way to clean this up and print the panic message I'm all in, otherwise I can remove the code that writes the nicer panic message and keep the silent panic, since it's enough for soundness. Especially since this PR is already a bit larger.

3) `SanitizeHWAddress`: When differentiating C++, Enzyme can use TBAA to "understand" enums/unions, but for Rust we don't have this information. LLVM might to speculative loads which (without TBAA) confuse Enzyme, so we disable those with this attribute. This attribute is only set during the first opt run before Enzyme differentiates code. We then remove it again once we are done with autodiff and run the opt pipeline a second time. Since enums are everywhere in Rust, support for them is crucial, but if this looks too cursed I can remove these ~100 lines and keep them in my fork for now, we can then discuss them separately to make this PR simpler?

4) Duplicated llvm-opt runs: Differentiating already optimized code (and being able to do additional optimizations on the fly, e.g. for GPU code) is _the_ reason why Enzyme is so fast, so the compile time is acceptable for autodiff users:  https://enzyme.mit.edu/talks/Publications/ (There are also algorithmic issues in Enzyme core which are more serious than running opt twice).

5) I assume that if we merge these minimal cg_ssa changes here already, I also need to fix the other backends (GCC and cliff) to have dummy implementations, correct?

6) *I'm happy to split this PR up further if reviewers have recommendations on how to.*

For the full implementation, see: https://github.com/rust-lang/rust/pull/129175

Tracking:

- https://github.com/rust-lang/rust/issues/124509
2025-01-02 00:20:57 +00:00
Matthias Krüger
92dbfcc2c0
Rollup merge of #135000 - compiler-errors:opaque-captures-dupe, r=lqd
Fix ICE when opaque captures a duplicated/invalid lifetime

See description on test.

Fixes #132766
Fixes #133693
Fixes #134780
2025-01-01 22:04:18 +01:00
Matthias Krüger
fa5acdc36f
Rollup merge of #134984 - compiler-errors:obligation-tweaks, r=lqd
`ObligationCause` construction tweaks in typeck

Mostly just consolidating the way we construct obligations in `FnCtxt`.
2025-01-01 22:04:17 +01:00
Manuel Drehwald
d753cbf779 upstream rustc_codegen_llvm changes for enzyme/autodiff 2025-01-01 21:42:45 +01:00
Michael Goulet
d3c6067275 Fix ICE when opaque captures a duplicated/invalid lifetime 2025-01-01 19:32:51 +00:00
Rémy Rakic
9d444c26c9 remove borrowck duplicate of std::ops::ControlFlow 2025-01-01 12:13:33 +00:00
Rémy Rakic
79d761d93c remove allow_two_phase_borrow
it's been simplified over the years, but now it's no longer useful.

- document its replacement in `BorrowKind`
- use that everywhere instead
2025-01-01 12:13:33 +00:00
Rémy Rakic
ff1aaa52ff remove empty util module 2025-01-01 12:13:33 +00:00
Rémy Rakic
56e7575ddd move find_assignments to its only use site
this is to remove the entire `util` module
2025-01-01 12:13:33 +00:00
Rémy Rakic
46154b2253 localize typeck constraints
it's still partially a skeleton, but works well enough for almost all tests to pass
2025-01-01 12:13:32 +00:00
Rémy Rakic
eb7da16408 move typeck constraints conversion to its own module 2025-01-01 12:13:32 +00:00
Stuart Cook
65cb7c66d0
Rollup merge of #134979 - estebank:default-lint-sugg, r=compiler-errors
Provide structured suggestion for `impl Default` of type where all fields have defaults

```
error: `Default` impl doesn't use the declared default field values
  --> $DIR/manual-default-impl-could-be-derived.rs:28:1
   |
LL | / impl Default for B {
LL | |     fn default() -> Self {
LL | |         B {
LL | |             x: s(),
   | |                --- this field has a default value
LL | |             y: 0,
   | |                - this field has a default value
...  |
LL | | }
   | |_^
   |
help: to avoid divergence in behavior between `Struct { .. }` and `<Struct as Default>::default()`, derive the `Default`
   |
LL ~ #[derive(Default)] struct B {
   |
```

Note that above the structured suggestion also includes completely removing the manual `impl`, but the rendering doesn't.
2025-01-01 16:35:32 +11:00
Stuart Cook
f91bfd97bf
Rollup merge of #134945 - compiler-errors:map-mutate-nits, r=estebank
Some small nits to the borrowck suggestions for mutating a map through index

1. Suggesting users to either use `.insert` or `.get_mut` (which do totally different things) can be a bit of a footgun, so let's make that a bit more nuanced.
2. I find the suggestion of `.get_mut(|val| { *val = whatever; })` to be a bit awkward. I changed this to be an if-let instead.
3. Fix a bug which was suppressing the structured suggestion for some mutations via the index operator on `HashMap`/`BTreeMap`.

r? estebank or reassign
2025-01-01 16:35:31 +11:00
Stuart Cook
1ea1db5b08
Rollup merge of #134877 - DavisRayM:129966-format-string-help-message, r=estebank
add suggestion for wrongly ordered format parameters

Add suggestion for wrongly ordered format parameters like `?#`.

Supersedes #131004
Fix #129966
2025-01-01 16:35:30 +11:00
Stuart Cook
0204259780
Rollup merge of #133292 - dianne:e0277-suggest-deref, r=estebank
E0277: suggest dereferencing function arguments in more cases

This unifies and generalizes some of the logic in `TypeErrCtxt::suggest_dereferences` so that it will suggest dereferencing arguments to function/method calls in order to satisfy trait bounds in more cases.

Previously it would only fire on reference types, and it had two separate cases (one specifically to get through custom `Deref` impls when passing by-reference, and one specifically to catch #87437). I've based the new checks loosely on what's done for `E0308` in `FnCtxt::suggest_deref_or_ref`: it will suggest dereferences to satisfy trait bounds whenever the referent is `Copy`, is boxed (& so can be moved out of the boxes), or is being passed by reference.

This doesn't make the suggestion fire in contexts other than function arguments or binary operators (which are in a separate case that this doesn't touch), and doesn't make it suggest a combination of `&`-removal and dereferences. Those would require a bit more restructuring, so I figured just doing this would be a decent first step.

Closes #90997
2025-01-01 16:35:30 +11:00
Stuart Cook
f4db757cb5
Rollup merge of #131439 - mu001999-contrib:cleanup/static-mut, r=estebank
Remove allowing static_mut_refs lint
2025-01-01 16:35:29 +11:00
Max Niederman
087b8721db typecheck guard pattern conditions 2024-12-31 17:32:46 -08:00
Max Niederman
b579c36224 add guard patterns to HIR and implement lowering 2024-12-31 17:21:29 -08:00
Trevor Gross
3d3d898a2e
Rollup merge of #133486 - dianne:fix-move-error-suggestion, r=estebank
borrowck diagnostics: make `add_move_error_suggestions` use the HIR rather than `SourceMap`

This PR aims to fix #132806 by rewriting `add_move_error_suggestions`[^1]. Previously, it manually scanned the source text to find a leading `&`, which isn't always going to produce a correct result (see: that issue). Admittedly, the HIR visitor in this PR introduces a lot of boilerplate, but hopefully the logic at its core isn't too complicated (I go over it in the comments). I also tried a simpler version that didn't use a HIR visitor and suggested adding `ref` always, but the `&ref x` suggestions really didn't look good. As a bonus for the added complexity though, it's now able to produce nice `&`-removing suggestions in more cases.

I tried to do this such that it avoids edition-dependent checks and its suggestions can be applied together with those from the match ergonomics 2024 migration lint. I haven't added tests for that since the details of match ergonomics 2024 are still being sorted out, but I can try if desired once that's finalized.

[^1]: In brief, it fires on patterns where users try to bind by-value in such a way that moves out of a reference to a non-Copy type (including slice references with non-copy elements). The suggestions are to change the binding's mode to be by-reference, either by removing[^2] an enclosing `&`/`&mut` or adding `ref` to the binding.

[^2]: Incidentally, I find the terminology of "consider removing the borrow" a bit confusing for a suggestion to remove a `&` pattern in order to make bindings borrow rather than move. I'm not sure what a good, concise way to explain that would be though, and that should go in a separate PR anyway.
2024-12-31 18:42:23 -05:00
Michael Goulet
1638948890 Obligation tweaks 2024-12-31 20:46:06 +00:00
Esteban Küber
2b2ea9e875 Provide structured suggestion for impl Default of type where all fields have defaults
```
error: `Default` impl doesn't use the declared default field values
  --> $DIR/manual-default-impl-could-be-derived.rs:28:1
   |
LL | / impl Default for B {
LL | |     fn default() -> Self {
LL | |         B {
LL | |             x: s(),
   | |                --- this field has a default value
LL | |             y: 0,
   | |                - this field has a default value
...  |
LL | | }
   | |_^
   |
help: to avoid divergence in behavior between `Struct { .. }` and `<Struct as Default>::default()`, derive the `Default`
   |
LL ~ #[derive(Default)] struct B {
   |
```

Note that above the structured suggestion also includes completely removing the manual `impl`, but the rendering doesn't.
2024-12-31 18:06:01 +00:00
Matthias Krüger
0c94f631d8
Rollup merge of #134956 - compiler-errors:format-args-hidden-chars, r=jieyouxu
Account for C string literals and `format_args` in `HiddenUnicodeCodepoints` lint

This is stacked on #134955, and either that can land first or both of them can land together here. I split this out because this is a bit more involved of an impl.

Fixes #94945
2024-12-31 14:30:44 +01:00
Ralf Jung
43ede97ebf arm: use target.llvm_floatabi over soft-float target feature 2024-12-31 12:41:20 +01:00
Ralf Jung
912b7291d0 add ABI target features *before* -Ctarget-features 2024-12-31 12:41:20 +01:00
Ralf Jung
eb527424a5 x86-64 hardfloat actually requires sse2 2024-12-31 12:41:20 +01:00
Ralf Jung
0a8cfc2f8f adjust GCC backend 2024-12-31 12:41:20 +01:00