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](a93616acf3..ae87d005bc?diff=unified&w=1))
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: (), .. };
| ++++
```
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
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.
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.
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).
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
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 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.
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`
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`
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
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`
Update our range `assume`s to the format that LLVM prefers
I found out in https://github.com/llvm/llvm-project/issues/123278#issuecomment-2597440158 that the way I started emitting the `assume`s in #109993 was suboptimal, and as seen in that LLVM issue the way we're doing it -- with two `assume`s sometimes -- can at times lead to CVP/SCCP not realize what's happening because one of them turns into a `ne` instead of conveying a range.
So this updates how it's emitted from
```
assume( x >= LOW );
assume( x <= HIGH );
```
or
```
// (for ranges that wrap the range)
assume( (x <= LOW) | (x >= HIGH) );
```
to
```
assume( (x - LOW) <= (HIGH - LOW) );
```
so that we don't need multiple `icmp`s nor multiple `assume`s for a single value, and both wrappping and non-wrapping ranges emit the same shape.
(And we don't bother emitting the subtraction if `LOW` is zero, since that's trivial for us to check too.)
The candidate shouldn't have false_edge_start_block if it has sub candidates.
In remove_never_subcandidates(), the false_edge_start_block from the first sub candidte is assigned to a value and the value is later used if all sub candidates are removed and candidate doesn't have false_edge_start_block.
In merge_trivial_subcandidates, I leave the if block which assign a false_edge_start_block into the candidate as before I put this commit since compile panics.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
The size of this struct depends on the alignment of `u128`, for example
powerpc64le and s390x have align-8 and end up with only 280 bytes. Our
64-bit tier-1 arches are the same though, so let's just assert on those.
Rollup of 8 pull requests
Successful merges:
- #132232 (CI: build FreeBSD artifacts on FreeBSD 13.4)
- #135706 (Move `supertrait_def_ids` into the elaborate module like all other fns)
- #135750 (Add an example of using `carrying_mul_add` to write wider multiplication)
- #135793 (Ignore `mermaid.min.js`)
- #135810 (Add Kobzol on vacation)
- #135821 (fix OsString::from_encoded_bytes_unchecked description)
- #135824 (tests: delete `cat-and-grep-sanity-check`)
- #135833 (Add fixme and test for issue #135289)
Failed merges:
- #135816 (Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors)
r? `@ghost`
`@rustbot` modify labels: rollup
```
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: `[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.
Add fixme and test for issue #135289
This PR:
- adds a test minimizing issue #135289 for PR #135310
- adds a fixme about the suboptimal fix for the ICE
I've verified the test indeed ICEs with 3f2f695d68 reverted.
r? `@estebank`
bump compiler and tools to windows 0.59, bootstrap to 0.57
This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57).
Bootstrap bumps only to 0.57 (the same sysinfo dep).
This additionally resolves my comment https://github.com/rust-lang/rust/pull/130874#issuecomment-2393562071
Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
When a struct definition has default field values, and the use struct ctor has missing field, 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 defaults, use `..`
|
LL | let _ = S { field: (), .. };
| ++++
```
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
Rework dyn trait lowering to stop being so intertwined with trait alias expansion
This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in https://github.com/rust-lang/rust/pull/133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable.
In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards.
Please review this with whitespace disabled.
r? lcnr
I think the diagnostic could use some work, but it's more helpful than
the alternative. The previous error was misleading, since it ignored the
inherited reference altogether.
The debug assertion ensuring that the pattern mutability cap holds
assumes the presence of Rule 3, so it now checks for that. I
considered going back to only tracking the mutability cap when Rule 3
is present, but since the mutability cap is used in Rule 5's
implementation too, the debug assertion would still need to check
which typing rules are present.
This also required some changes to tests:
- `ref_pat_eat_one_layer_2021.rs` had a test for Rule 3; I'll be
handling tests for earlier editions in a later commit, so as a stopgap
I've #[cfg]ed it out.
- One test case had to be moved from `well-typed-edition-2024.rs` to
`borrowck-errors.rs` in order to get borrowck to run on it and emit an
error.
These targets have always generated DWARF debuginfo and not CodeView/PDB debuginfo
like the MSVC Windows targets. Correct their target definitions to reflect this.
The newly added tests for the various combinations of `*-windows-gnu*` targets and
`-Csplit-debuginfo` show that this does not change any stable behavior.
Subtree sync for rustc_codegen_cranelift
Nothing too exciting this time, but this includes a fix for a linker hang on Windows: https://github.com/rust-lang/rustc_codegen_cranelift/pull/1554
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase
Part of #132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro
- Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro.
- Skipped `.md` files and test files to avoid unnecessary changes.
Rollup of 5 pull requests
Successful merges:
- #135433 (Add Profile Override for Non-Git Sources)
- #135626 (doc: Point to methods on `Command` as alternatives to `set/remove_var`)
- #135658 (Do not include GCC source code in source tarballs)
- #135676 (rustc_resolve: use structured fields in traces)
- #135762 (Correct counting to four in cell module docs)
r? `@ghost`
`@rustbot` modify labels: rollup
When LLVM's location discriminator value limit is exceeded, emit locations with dummy spans instead of dropping them entirely
Dropping them fails `-Zverify-llvm-ir`.
Fixes#135332.
r? `@jieyouxu`
rustc_resolve: use structured fields in traces
I think this crate was written before `tracing` was adopted, and was manually writing fields into trace logs instead of using structured fields.
I kept function names in the trace messages even though I added `#[instrument]` invocations so that the events will be in named spans, wasn't sure if spans are always printed.
Rollup of 7 pull requests
Successful merges:
- #135542 (Add the concrete syntax for precise capturing to 1.82 release notes.)
- #135700 (Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy)
- #135722 (make it possible to use ci-rustc on tarball sources)
- #135729 (Add debug assertions to compiler profile)
- #135736 (rustdoc: Fix flaky doctest test)
- #135738 (Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`)
- #135747 (Rename FileName::QuoteExpansion to CfgSpec)
r? `@ghost`
`@rustbot` modify labels: rollup
Always force non-trimming of path in `unreachable_patterns` lint
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix#135289.
Match Ergonomics 2024: document and reorganize the currently-implemented feature gates
The hope here is to make it easier to adjust, understand, and test the experimental pattern typing rules implemented in the compiler. This PR doesn't (or at isn't intended to) change any behavior or add any new tests; I'll be handling that later. I've also included some reasoning/commentary on the more involved changes in the commit messages.
Relevant tracking issue: #123076
r? `@Nadrieril`
fully de-stabilize all custom inner attributes
`#![test]` and `#![rustfmt::skip]` were accidentally accepted in more places than they should. These have been marked as soft-unstable since forever (https://github.com/rust-lang/rust/pull/82399) and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274).
Cc `@rust-lang/lang` `@petrochenkov`
Rename FileName::QuoteExpansion to CfgSpec
I believe this variant name was used incorrectly. The timeline is roughly:
* `FileName::cfg_spec_source_code` was added in https://github.com/rust-lang/rust/pull/54517. However, it used `FileName::Quote` instead of `FileName::CfgSpec` which I believe was a mistake.
* Quote stuff was removed in https://github.com/rust-lang/rust/pull/51285, but did not remove `FileName::Quote`.
* `FileName::CfgSpec` was removed in https://github.com/rust-lang/rust/pull/116474 because it was unused.
This restores it so that the `--cfg` variant uses a name that makes more sense with how it is used, and restores what I think is the original intent.
Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`
Split out from #135732 according to https://github.com/rust-lang/rust/pull/135732?pullrequestreview-2561072330 ,
same thing but just for the compiler:
> The usage of `map_or(bool, ...)` is really hard to understand IMHO.
> This PR simply uses clippy (with `--fix`) to replace that with `is_{some_and|none_or|ok_and}`.
> (no manual modifications were made, just machine applicable clippy fixes and then fmt)
r? ``@compiler-errors``
Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy
Add test ensuring that struct with default field values is not constructable if the fields are not accessible.
Collect all unreachable fields in a single struct literal struct and emit a single error, instead of one error per private field.
```
error[E0451]: fields `beta` and `gamma` of struct `Alpha` are private
--> $DIR/visibility.rs:18:13
|
LL | let _x = Alpha {
| ----- in this type
LL | beta: 0,
| ^^^^^^^ private field
LL | ..
| ^^ field `gamma` is private
```
This adds explanation of inherited references and how they relate to the default binding mode.
Co-authored-by: Nadrieril <Nadrieril@users.noreply.github.com>
I believe this variant name was used incorrectly. The timeline is roughly:
* `FileName::cfg_spec_source_code` was added in
https://github.com/rust-lang/rust/pull/54517. However, it used
`FileName::Quote` instead of `FileName::CfgSpec` which I believe was a
mistake.
* Quote stuff was removed in
https://github.com/rust-lang/rust/pull/51285, but did not remove
`FileName::Quote`.
* `FileName::CfgSpec` was removed in
https://github.com/rust-lang/rust/pull/116474 because it was unused.
This restores it so that the `--cfg` variant uses a name that makes more
sense with how it is used, and restores what I think is the original
intent.
Revert most of #133194 (except the test and the comment fixes). Then refix
not emitting locations at all when the correct location discriminator value
exceeds LLVM's capacity.
Don't skip argument parsing when running `rustc` with no arguments
Setting up the argument parser to parse no arguments is a tiny bit of wasted work, but avoids an otherwise-unnecessary special case, in a scenario (printing a help message and quitting) where perf at this scale really doesn't matter anyway.
In particular, this lets us avoid having to deal with multiple different APIs to determine whether the compiler is nightly or not.
---
This special-case handling for rustc with no arguments is very very old (long predating 1.0), and used to be much simpler, without any need to set up boolean values to handle various conditional cases. So I don't think it was ever explicitly decided that having this special case was worth the extra complexity; it just started out simple and accumulated complexity over time.
Setting up the argument parser to parse no arguments is a tiny bit of wasted
work, but avoids an otherwise-unnecessary special case.
In particular, this lets us avoid having to deal with multiple different APIs
to determine whether the compiler is nightly or not.
Some random compiler nits
The only "observable" change here is using `par_body_owners` for coroutine witnesses/coroutine obligation checking.
r? lqd (or reassign, you just seem to like to approve prs :3 )
Disallow `A { .. }` if `A` has no fields
```
error: `A` has no fields, `..` needs at least one default field in the struct definition
--> $DIR/empty-struct.rs:16:17
|
LL | let _ = A { .. };
| - ^^
| |
| this type has no fields
```
Get rid of `ToPolyTraitRef`
It's generally a footgun, since it throws away `PredicatePolarity`.
This PR doesn't attempt to fix any related bugs having to do with binders or polarity; it just tries to pass through `TraitPredicate`s around instead of `TraitRef`s. There should be basically no functional changes.
Fix ICE in resolving associated items as non-bindings
Fixes#135614 so that imported associated functions of traits can be shadowed by local bindings and associated constants of traits can be used in patterns.
```
error[E0797]: base expression required after `..`
--> $DIR/feature-gate-default-field-values.rs:62:21
|
LL | let x = Foo { .. };
| ^
|
help: add `#![feature(default_field_values)]` to the crate attributes to enable default values on `struct` fields
|
LL + #![feature(default_field_values)]
|
help: add a base expression here
|
LL | let x = Foo { ../* expr */ };
| ++++++++++
```
```
error: `size_of_val` is not yet stable as a const intrinsic
--> $DIR/const-unstable-intrinsic.rs:17:9
|
LL | unstable_intrinsic::size_of_val(&x);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: add `#![feature(unstable)]` to the crate attributes to enable
help: add `#![feature(unstable)]` to the crate attributes to enable
|
LL + #![feature("unstable")]
|
```
When encountering a call corresponding to an item marked as unstable behind a feature flag, provide a structured suggestion pointing at where in the crate the `#![feature(..)]` needs to be written.
```
error: `foobar` is not yet stable as a const fn
--> $DIR/const-stability-attribute-implies-no-feature.rs:12:5
|
LL | foobar();
| ^^^^^^^^
|
help: add `#![feature(const_foobar)]` to the crate attributes to enable
|
LL + #![feature(const_foobar)]
|
```
Fix#81370.
```
error: `A` has no fields, `..` needs at least one default field in the struct definition
--> $DIR/empty-struct.rs:16:17
|
LL | let _ = A { .. };
| - ^^
| |
| this type has no fields
```
Collect all unreachable fields in a single struct literal struct and emit a single error, instead of one error per private field.
```
error[E0451]: fields `beta` and `gamma` of struct `Alpha` are private
--> $DIR/visibility.rs:18:13
|
LL | let _x = Alpha {
| ----- in this type
LL | beta: 0,
| ^^^^^^^ private field
LL | ..
| ^^ field `gamma` is private
```
Rollup of 7 pull requests
Successful merges:
- #133700 (const-eval: detect more pointers as definitely not-null)
- #135290 (Encode constraints that hold at all points as logical edges in location-sensitive polonius)
- #135478 (Run clippy for rustc_codegen_gcc on CI)
- #135583 (Move `std::pipe::*` into `std::io`)
- #135612 (Include x scripts in tarballs)
- #135624 (ci: mirror buildkit image to ghcr)
- #135661 (Stabilize `float_next_up_down`)
r? `@ghost`
`@rustbot` modify labels: rollup
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)
const-eval: detect more pointers as definitely not-null
This fixes https://github.com/rust-lang/rust/issues/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.`
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.
- Move `make_bcb_counters` out of `CoverageCounters`
- Split out `make_node_counter_priority_list`
- Flatten `Transcriber` into the function `transcribe_counters`
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
```
error[E0451]: field `x` of struct `S` is private
--> $DIR/visibility.rs:24:9
|
LL | let a = baz::S {
| ------ in this type
LL | ..
| ^^ field `x` is private
```
Stable Hash: Ignore all HirIds that just identify the node itself
This should provide better incremental caching, but it seems there is more to it.
These IDs also serve no purpose being in the stable hash of the item they refer to, only when referring to *another* item is it important that we hash the `HirId`. So we can at least avoid the cost during stable hashing, even if we don't benefit from it by avoiding some queries' caches from being invalidated
Unsure how to make sure we do this right by construction. Would be nice to do something type based
Instead of materializing `Locations::All` constraints as physical edges
at all the points in the CFG, we record them as logical edges and only
materialize them during traversal as successors for a given node.
This fixes the slowness/hang in the `saturating-float-casts.rs` test.
Expand docs for `E0207` with additional example
Add an example to E0207 docs showing how to tie the lifetime of the self type to an associated type in an impl when the trait *doesn't* have a lifetime to begin with.
CC #135589.
Detect if-else chains with a missing final else in type errors
```
error[E0308]: `if` and `else` have incompatible types
--> $DIR/if-else-chain-missing-else.rs:12:12
|
LL | let x = if let Ok(x) = res {
| ______________-
LL | | x
| | - expected because of this
LL | | } else if let Err(e) = res {
| | ____________^
LL | || return Err(e);
LL | || };
| || ^
| ||_____|
| |_____`if` and `else` have incompatible types
| expected `i32`, found `()`
|
= note: `if` expressions without `else` evaluate to `()`
= note: consider adding an `else` block that evaluates to the expected type
```
We probably want a longer explanation and fewer spans on this case.
Partially address #133316.
Location-sensitive polonius prototype: endgame
This PR sets up the naive location-sensitive analysis end-to-end, and replaces the location-insensitive analysis. It's roughly all the in-progress work I wanted to land for the prototype, modulo cleanups I still want to do after the holidays, or the polonius debugger, and so on.
Here, we traverse the localized constraint graph, have to deal with kills and time-traveling (👌), and record that as loan liveness for the existing scope and active loans computations.
Then the near future looks like this, especially if the 2025h1 project goal is accepted:
- gradually bringing it up to completion
- analyzing and fixing the few remaining test failures
- going over the *numerous* fixmes in this prototype (one of which is similar to a hang on one test's millions and millions of constraints)
- trying to see how to lower the impact of the lack of NLL liveness optimization on diagnostics, and their categorization of local variables and temporaries (the vast majority of blessed expectations differences), as well as the couple ICEs trying to find an NLL constraint to blame for errors.
- dealing with the theoretical weakness around kills, conflating reachability for the two TCS, etc that is described ad nauseam in the code.
- switching the compare mode to the in-tree implementation, and blessing the diagnostics
- apart from the hang, it's not catastrophically slower on our test suite, so then we can try to enable it on CI
- checking crater, maybe trying to make it faster :3, etc.
I've tried to gradually introduce this PR's work over 4 commits, because it's kind of subtle/annoying, and Niko/I are not completely convinced yet. That one comment explaining the situation is maybe 30% of the PR 😓. Who knew that spacetime reachability and time-traveling could be mind bending.
I kinda found this late and the impact on this part of the computation was a bit unexpected to us. A bit more care/thought will be needed here. I've described my plan in the comments though. In any case, I believe we have the current implementation is a conservative approximation that shouldn't result in unsoundness but false positives at worst. So it feels fine for now.
r? ``@jackh726``
---
Fixes#127628 -- which was a assertion triggered for a difference in loan computation between NLLs and the location-insensitive analysis. That doesn't exist anymore so I've removed this crash test.
Add gpu-kernel calling convention
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target.
Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
Tracking issue: #135467
amdgpu target tracking issue: #135024
Use trait definition cycle detection for trait alias definitions, too
fixes#133901
In general doing this for `All` is not right, but this code path is specifically for traits and trait aliases, and there we only ever use `All` for trait aliases.
Update docs for `-Clink-dead-code` to discourage its use
The `-Clink-dead-code` flag was originally added way back in #31368, apparently to help improve the output of some older forms of code coverage measurement, and also to address some use-cases for wanting to suppress linker flags like `-dead_strip` and `--gc-section`.
In the past it might have also been useful in conjunction with `-Cinstrument-coverage`, but subsequent improvements to coverage instrumentation have made it unnecessary there.
[It is also currently used by cargo-fuzz by default](https://github.com/rust-fuzz/cargo-fuzz/issues/391), for reasons that are possibly no longer relevant.
---
The flag currently does more than its name suggests, affecting not just linker flags, but also monomorphization decisions. It has also contributed to ICEs (e.g. #135515) that would not have occurred without link-dead-code.
---
For now, this PR just updates the documentation to be more realistic about what the flag does, and when it should be used (approximately never). In the future, it might be worth looking into properly deprecating this flag, and perhaps making it a no-op if feasible.
coverage: Completely overhaul counter assignment, using node-flow graphs
The existing code for choosing where to put physical counter-increments gets the job done, but is very ad-hoc and hard to modify without introducing tricky regressions.
This PR replaces all of that with a more principled approach, based on the algorithm described in "Optimal measurement points for program frequency counts" (Knuth & Stevenson, 1973).
---
We start by ensuring that our graph has “balanced flow”, i.e. each node's flow (execution count) is equal to the sum of all its in-edge flows, and equal to the sum of all its out-edge flows. That isn't naturally true of control-flow graphs, so we introduce a wrapper type `BalancedFlowGraph` to fix that by introducing synthetic nodes and edges as needed.
Once our graph has balanced flow, the next step is to create another view of that graph in which each node's successors have all been merged into one “supernode”. Consequently, each node's out-edges can be coalesced into a single out-edge to one of those supernodes. Because of the balanced-flow property, the flow of that coalesced edge is equal to the flow of the original node.
Having expressed all of our node flows as edge flows, we can then analyze node flows using techniques for analyzing edge flows. We incrementally build a spanning tree over the merged supernodes, such that each new edge in the spanning tree represents a node whose flow can be computed from that of other nodes.
When this is done, we end up with a list of “counter terms” for each node, describing which nodes need physical counters, and how the remaining nodes can have their flow calculated by adding and subtracting those physical counters.
---
The re-blessed coverage tests show that this results in modest or major improvements for our test programs. Some tests need fewer physical counters, some tests need fewer expression nodes for the same number of physical counters, and some tests show striking reductions in both.
Fix overflows in the implementation of `overflowing_literals` lint's help
This PR fixes two overflow problems that cause the `overflowing_literals` lint to behave incorrectly in some edge cases.
1. When an integer literal is between `i128::MAX` and `u128::MAX`, an overflowing `as` cast can cause the suggested type to be overly small. It's fixed by using checked type conversion and returning `u128` when it's the only choice. (Fixes#135248)
2. When an integer literal is `i128::MIN` but is of a smaller type, an overflowing negation cause the compiler to panic in debug build. Fixed by checking the number size beforehand and `wrapping_neg`. (Fixes#131849)
Edit: extracted the type conversion part into a standalone function to separate the concern of overflowing.
[cfg_match] Adjust syntax
A year has passed since the creation of #115585 and the feature, as expected, is not moving forward. Let's change that.
This PR proposes changing the arm's syntax from `cfg(SOME_CONDITION) => { ... }` to `SOME_CODITION => {}`.
```rust
match_cfg! {
unix => {
fn foo() { /* unix specific functionality */ }
}
target_pointer_width = "32" => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
Why? Because after several manual migrations in https://github.com/rust-lang/rust/pull/116342 it became clear, at least for me, that `cfg` prefixes are unnecessary, verbose and redundant.
Again, everything is just a proposal to move things forward. If the shown syntax isn't ideal, feel free to close this PR or suggest other alternatives.
Some targets have many different CPUs and no generic CPU that can be
used as a default. For these targets, the user needs to explicitly
specify a CPU through `-C target-cpu=`.
Add an option for targets and an error message if no CPU is set.
This affects the proposed amdgpu and avr targets.
```
error[E0308]: `if` and `else` have incompatible types
--> $DIR/if-else-chain-missing-else.rs:12:12
|
LL | let x = if let Ok(x) = res {
| ______________-
LL | | x
| | - expected because of this
LL | | } else if let Err(e) = res {
| | ____________^
LL | || return Err(e);
LL | || };
| || ^
| ||_____|
| |_____`if` and `else` have incompatible types
| expected `i32`, found `()`
|
= note: `if` expressions without `else` evaluate to `()`
= note: consider adding an `else` block that evaluates to the expected type
```
We probably want a longer explanation and fewer spans on this case.
Partially address #133316.
The amdgpu-kernel calling convention was reverted in commit
f6b21e90d1 due to inactivity in the amdgpu
target.
Introduce a `gpu-kernel` calling convention that translates to
`ptx_kernel` or `amdgpu_kernel`, depending on the target that rust
compiles for.
Rollup of 5 pull requests
Successful merges:
- #135497 (fix typo in typenames of pin documentation)
- #135522 (add incremental test for issue 135514)
- #135523 (const traits: remove some known-bug that do not seem to make sense)
- #135535 (Add GUI test for #135499)
- #135541 (Methods of const traits are const)
r? `@ghost`
`@rustbot` modify labels: rollup
Prefer lower `TraitUpcasting` candidates in selection
Fixes#135463. The underlying cause is this ambiguity, but it's more clear (and manifests as a coercion error, rather than a MIR validation error) when it's written the way I did in the UI test.
Sorry this is cursed r? lcnr
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
Rollup of 7 pull requests
Successful merges:
- #132397 (Make missing_abi lint warn-by-default.)
- #133807 (ci: Enable opt-dist for dist-aarch64-linux builds)
- #134143 (Convert `struct FromBytesWithNulError` into enum)
- #134338 (Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics)
- #134678 (Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`)
- #135424 (Detect unstable lint docs that dont enable their feature)
- #135520 (Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs)
r? `@ghost`
`@rustbot` modify labels: rollup
Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs
Absolutely clueless mistake of mine. Whoops.
When eagerly collecting mono items, when we encounter an ADT, we try to monomorphize its drop glue. In #135313, I made it so that this acts more like eagerly monomorphizing functions, where we allow (in this case) ADTs with lifetimes, since those can be erased by codegen.
However, I did not account for the call to `instantiate_and_check_impossible_predicates`, which was still passing an empty set of args. This means that if the ADT in question had any predicates, we'd get an index out of bounds panic.
This PR creates the correct set of args for the ADT.
Fixes#135515. I assume that this manifests in that issue because of `-Clink-dead-code` or something.
Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics
Combined with [1], this will change the overflowing multiplication operations to return an `extern "C"`-safe type.
Link: https://github.com/rust-lang/compiler-builtins/pull/735 [1]
Do not consider traits that have unsatisfied const conditions to be conditionally const
This will improve error messages as we continue to constify traits, since we don't want to start calling things "conditionally const" if they aren't implemented with a const impl anyways.
The only case that this affects today is `Deref` since that's one of the only constified traits in the standard library :)
r? RalfJung
Enforce syntactical stability of const traits in HIR
This PR enforces what I'm calling *syntactical* const stability of traits. In other words, it enforces the ability to name `~const`/`const` traits in trait bounds in various syntax positions in HIR (including in the trait of an impl header). This functionality is analogous to the *regular* item stability checker, which is concerned with making sure that you cannot refer to unstable items by name, and is implemented as an extension of that pass.
This is separate from enforcing the *recursive* const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new `NonConstOp` to the const checker and probably adjusting some logic to deduplicate redundant errors.
However, this check is separate and necessary for making sure that users don't add `~const`/`const` bounds to items when the trait is not const-stable in the first place. I chose to separate enforcing recursive const stability out of this PR to make it easier to review. I'll probably open a follow-up following this one, blocked on this PR.
r? `@RalfJung` cc `@rust-lang/project-const-traits`
Make sure we can produce `ConstArgHasWrongType` errors for valtree consts
I forgot about `ty::ConstKind::Value` in #134771.
The error message here could use some work -- both in the new trait solver and the old trait solver. But unrelated to the issue here.
Fixes https://github.com/rust-lang/rust/issues/135361 -- this was only ICEing in coherence because coherence uses the new trait solver, but I don't think the minimization is worth committing compared to the test I added.
r? ```@lcnr``` or ```@BoxyUwU```
Improve `DispatchFromDyn` and `CoerceUnsized` impl validation
* Disallow arbitrary 1-ZST fields in `DispatchFromDyn` -- only `PhantomData`, and 1-ZSTs that mention no params (which is needed to support, e.g., the `Global` alloctor in `Box<T, U = Global>`).
* Don't allow coercing between non-ZSTs to ZSTs (since the previous check wasn't actually checking the field tys were the same before checking the layout...)
* Normalize the field before checking it's `PhantomData`.
Fixes#135215Fixes#135214Fixes#135220
r? ```@BoxyUwU``` or reassign
Make sure to scrape region constraints from deeply normalizing type outlives assumptions in borrowck
Otherwise we're just randomly registering these region relations into the infcx which isn't good
r? lcnr
Rollup of 7 pull requests
Successful merges:
- #134216 (Enable "jump to def" feature on patterns)
- #134880 (Made `Path::name` only have item name rather than full name)
- #135466 (Leak check in `impossible_predicates` to avoid monomorphizing impossible instances)
- #135476 (Remove remnant of asmjs)
- #135479 (mir borrowck: cleanup late-bound region handling)
- #135493 (Fix legacy symbol mangling of closures)
- #135495 (Add missing closing backtick in commit hook message 🐸)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix legacy symbol mangling of closures
When this code was written, there was no `type_of` implementation for closures. That has long since been changed.
In the UI test:
```
trait A where
[(); (|| {}, 1).1]: Sized,
{
}
```
We tried to walk up the def path tree for the closure, from closure -> anon const -> trait. When we reached the trait, we tried to call `type_of` on it which obviously doesn't do the right thing and ICEs.
Fixes#135418
Eagerly mono drop for structs with lifetimes
That is, use `!generics.requires_monomorphization()` rather than `generics.is_empty()` like the rest of the mono collector code.
Exclude dependencies of `std` for diagnostics
Currently crates in the sysroot can show up in diagnostic suggestions, such as in https://github.com/rust-lang/rust/issues/135232. To prevent this, duplicate `all_traits` into `visible_traits` which only shows traits in non-private crates.
Setting `#![feature(rustc_private)]` overrides this and makes items in private crates visible as well, since `rustc_private` enables use of `std`'s private dependencies.
This may be reviewed per-commit.
Fixes: https://github.com/rust-lang/rust/issues/135232
This is similar to the existing `union`, except that bits in the RHS are
negated before being incorporated into the LHS.
Currently only `DenseBitSet` is supported. Supporting other bitset types is
possible, but non-trivial, and currently isn't needed.
In order to avoid diagnostics suggesting stdlib-private dependencies,
make everything that is a direct dependency of any `std` crates private
by default. Note that this will be overridden, if the same crate is
public elsewhere in the crate graph then that overrides the private
default.
It may also be feasible to do this in the library crate, marking `std`'s
dependencies private via Cargo. However, given that the feature is still
rather unstable, doing this within the compiler seems more
straightforward.
Fixes: https://github.com/rust-lang/rust/issues/135232 [1]
Add an alternative to `tcx.all_traits()` that only shows traits that the
user might be able to use, for diagnostic purposes. With this available,
make use of it for diagnostics including associated type errors, which
is part of the problem with [1].
Includes a few comment updates for related API.
[1]: https://github.com/rust-lang/rust/issues/135232
Really this is always-visible override only needs to happen when the
crate is a dependency of itself. However, this is a very internal
feature, so it doesn't seem worth doing any additional filtering here.
Currently `root` or `crate_root` is used to refer to an instance of
`CrateRoot` (representation of a crate's serialized metadata), but the
name `root` sometimes also refers to a `CratePath` representing a "root"
node in the dependency graph. In order to disambiguate, rename all
instances of the latter to `dep_root`.
fix ICE with references to infinite structs in consts
fixes https://github.com/rust-lang/rust/issues/114484
Normalizing `<Type as Pointee>::Metadata` may emit a (non-fatal) error during trait selection if finding the struct tail of `Type` hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize to `ty::Error` instead.
This is important, because to compute the layout of `&Type` we need to compute the layout of `<Type as Pointee>::Metadata`
2ae9916816/compiler/rustc_ty_utils/src/layout.rs (L247-L273)
and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:
```rust
trait Project {
type Assoc;
}
fn foo<T: Project>() {
[(); {
let _: Option<T::Assoc> = None;
// ^^^^^^^^ this projection is rigid, so we can't know it's layout
0
}];
}
```
```
error: constant expression depends on a generic parameter
--> src/lib.rs:6:10
|
6 | [(); {
| __________^
7 | | let _: Option<T::Assoc> = None;
8 | | // ^^^^^^^^ this projection is rigid, so we can't know it's layout
9 | | 0
10 | | }];
| |_____^
|
= note: this may fail depending on what value the parameter takes
```
For non-generic rigid projections we will currently ICE, because we incorrectly assume that `LayoutError::Unknown` means that a const must be generic (https://github.com/rust-lang/rust/issues/135138). This is being fixed and turned into a proper error in https://github.com/rust-lang/rust/pull/135158.
```rust
#![feature(trivial_bounds)]
trait Project {
type Assoc;
}
fn foo()
where
u8: Project,
{
[(); {
let _: Option<<u8 as Project>::Assoc> = None; // ICEs currently, but will be an error
0
}];
}
```
However, if we hit the recursion limit when normalizing `<Type as Pointee>::Metadata` we don't want to report a layout error, because we already emitted the recursion error. So by normalizing to `ty::Error` here, we get a `LayoutError::ReferencesError` instead of a `LayoutError::Unknown` and don't report the layout error to the user.
Remove code duplication when hashing query result and interning node
Refactored the duplicated code into a function.
`with_feed_task` currently passes the query key to `debug_assert!`. I believe that's a mistake, since `with_task` prints the `DepNode` which is more sensible, so this commit changes that, so it debug prints the `DepNode`.
Fix emscripten-wasm-eh with unwind=abort
If we build the standard library with wasm-eh then we need to link with `-fwasm-exceptions` even if we compile with `panic=abort`.
Without this change, linking a `panic=abort` crate fails with: `undefined symbol: __cpp_exception`.
Followup to #131830.
r? workingjubilee
Make sure to mark `IMPL_TRAIT_REDUNDANT_CAPTURES` as `Allow` in edition 2024
I never got sign-off on #127672 for this lint being warn by default in edition 2024, so let's turn downgrade this lint to allow for now.
Should be backported so it ships with the edition.
```@rustbot``` label: +beta-nominated
Detect `mut arg: &Ty` meant to be `arg: &mut Ty` and provide structured suggestion
When a newcomer attempts to use an "out parameter" using borrows, they sometimes get confused and instead of mutating the borrow they try to mutate the function-local binding instead. This leads to either type errors (due to assigning an owned value to a mutable binding of reference type) or a multitude of lifetime errors and unused binding warnings.
This change adds a suggestion to the type error
```
error[E0308]: mismatched types
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:6:14
|
LL | fn change_object(mut object: &Object) {
| ------- expected due to this parameter type
LL | let object2 = Object;
LL | object = object2;
| ^^^^^^^ expected `&Object`, found `Object`
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
and to the unused assignment lint
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:11:5
|
LL | object = &object2;
| ^^^^^^
|
note: the lint level is defined here
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:1:9
|
LL | #![deny(unused_assignments, unused_variables)]
| ^^^^^^^^^^^^^^^^^^
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object2(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
Fix#112357.
Fix cycle error only occurring with -Zdump-mir
fixes#134205
During mir dumping, we evaluate static items to render their allocations. If a static item refers to itself, its own MIR will have a reference to itself, so during mir dumping we end up evaluating the static again, causing us to try to build MIR again (mir dumping happens during MIR building).
Thus I disabled evaluation of statics during MIR dumps in case the MIR body isn't far enough along yet to be able to be guaranteed cycle free.
If we build the standard library with wasm-eh then we need to link
with `-fwasm-exceptions` even if we compile with `panic=abort`
Without this change, linking a `panic=abort` crate fails with:
`undefined symbol: __cpp_exception`.
Followup to #131830.
Refactored the duplicated code into a function.
`with_feed_task` currently passes the query key to `debug_assert!`.
This commit changes that, so it debug prints the `DepNode`, as in
`with_task`.
Assert that `Instance::try_resolve` is only used on body-like things
`Instance::resolve` is not set up to resolve items that are not body-like things. The logic in `resolve_associated_item` very much encodes this assumption:
e7ad3ae331/compiler/rustc_ty_utils/src/instance.rs (L96-L386)
However, some diagnostics were using `Instance::resolve` on an associated type, and it was simply a lucky coicidence that nothing went wrong.
This PR adds an assertion to make sure we won't do this again in the future, and fixes two callsites:
1. `call_kind` which returns a `CallKind` enum to categorize what a call in MIR comes from, and was using `Instance::resolve` to point at the associated type `Deref::Target` for a specific self ty.
2. `MirBorrowckCtxt::explain_deref_coercion`, which was doing the same thing.
The logic was replaced with `specialization_graph::assoc_def`, which is the proper way of fetching the right `AssocItem` for a given impl.
r? `@lcnr` or re-roll :)
fix handling of ZST in win64 ABI on windows-msvc targets
The Microsoft calling conventions do not really say anything about ZST since they do not seem to exist in MSVC. However, both GCC and clang allow passing ZST over `__attribute__((ms_abi))` functions (which matches our `extern "win64" fn`) on `windows-gnu` targets, and therefore implicitly define a de-facto ABI for these types (and lucky enough they seem to define the same ABI). This ABI should be the same for windows-msvc and windows-gnu targets, so we use this as a hint for how to implement this ABI everywhere: we always pass ZST by-ref.
The best alternative would be to just reject compiling functions which cannot exist in MSVC, but that would be a breaking change.
Cc `@programmerjake` `@ChrisDenton`
Fixes https://github.com/rust-lang/rust/issues/132893
Depth limit const eval query
Currently the const-eval query doesn't have a recursion limit or timeout, causing the complier to freeze in an infinite loop, see #125718. This PR depth limits the `eval_to_const_value_raw` query (with the [`recursion_limit`](https://doc.rust-lang.org/reference/attributes/limits.html) attribute) and improves the diagnostics for query overflow errors, so spans are reported for other dep kinds than `layout_of` (e.g. `eval_to_const_value_raw`).
fixes#125718fixes#114192
Remove allocations from case-insensitive comparison to keywords
Follows up on work in 99d02fb40f, expanding the alloc-free comparisons to more cases of case-insensitive keyword matching.
r? ghost for perf
Update unstable lint docs to include required feature attributes
closes#135298
## Summary
This PR updates the documentation examples for the following unstable lints to ensure they include the necessary feature attributes for proper usage:
- fuzzy_provenance_casts
- lossy_provenance_casts
- unqualified_local_imports
- test_unstable_lint
## Changes Made:
- Added the appropriate #![feature(...)] attributes to the example code for each lint.
- Updated the examples to produce correct and meaningful warnings, ensuring they align with current lint behavior.
Reference:
- Used the `must_not_suspend` lint documentation as a template for these updates.
De-abstract tagged ptr and make it covariant
In #135272 I needed to use a tagged ptr in `hir::TyKind` in order to not regress hir type sizes. Unfortunately the existing `CopyTaggedPtr` abstraction is insufficient as it makes the `'hir` lifetime invariant.
I spent some time trying to keep existing functionality while making it covariant but in the end I realised that actually we dont use *any* of this code *anywhere* in rustc, so I've just removed everything and replaced it with a much less general abstraction that is suitable for what I need in #135272.
Idk if anyone has a preference for just keeping all the abstractions here in case anyone needs them in the future 🤷♀️
If all subcandidates have never-pattern, we should assign false_edge_start_block to the parent candidate
if it doesn't have. merge_trivial_subcandidates does so, but if the candidate has guard it returns before the assignment.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
If all subcandidates have never-pattern, the parent candidate should have otherwise_block
because some methods expect the candidate has the block.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
Rollup of 6 pull requests
Successful merges:
- #129259 (Add inherent versions of MaybeUninit methods for slices)
- #135374 (Suggest typo fix when trait path expression is typo'ed)
- #135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass)
- #135378 (Remove a bunch of diagnostic stashing that doesn't do anything)
- #135397 (compiletest: add erroneous variant to `string_enum`s conversions error)
- #135398 (add more crash tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a bunch of diagnostic stashing that doesn't do anything
#121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them.
The net effect is:
1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler.
2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
Make MIR cleanup for functions with impossible predicates into a real MIR pass
It's a bit jarring to see the body of a function with an impossible-to-satisfy where clause suddenly go to a single `unreachable` terminator when looking at the MIR dump output in order, and I discovered it's because we manually replace the body outside of a MIR pass.
Let's make it into a fully flegded MIR pass so it's more clear what it's doing and when it's being applied.
Suggest typo fix when trait path expression is typo'ed
When users write something like `Default::defualt()` (notice the typo), failure to resolve the erroneous `defualt` item will cause resolution + lowering to interpret this as a type-dependent path whose self type is `Default` which is a trait object without `dyn`, rather than a trait function like `<_ as Default>::default()`.
Try to provide a bit of guidance in this situation when we can detect the typo.
Fixes https://github.com/rust-lang/rust/issues/135349
Add inherent versions of MaybeUninit methods for slices
This is my attempt to un-stall #63569 and #79995, by creating methods that mirror the existing `MaybeUninit` API:
```rust
impl<T> MaybeUninit<T> {
pub fn write(&mut self, value: T) -> &mut T;
pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
pub unsafe fn assume_init_drop(&mut self);
pub unsafe fn assume_init_ref(&self) -> &T;
pub unsafe fn assume_init_mut(&mut self) -> &mut T;
}
```
Adding these APIs:
```rust
impl<T> [MaybeUninit<T>] {
// replacing copy_from_slice; renamed to avoid conflict
pub fn write_copy_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Copy;
// replacing clone_from_slice; renamed to avoid conflict
pub fn write_clone_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Clone;
// identical to non-slice versions; no conflict
pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
pub unsafe fn assume_init_drop(&mut self);
pub unsafe fn assume_init_ref(&self) -> &[T];
pub unsafe fn assume_init_mut(&mut self) -> &mut [T];
}
```
Since the `assume_init` methods are identical to those on non-slices, they feel pretty natural. The main issue with the write methods is naming, as discussed in #79995 among other places. My rationale:
* The term "write" should be in them somewhere, to mirror the other API, and this pretty much automatically makes them not collide with any other inherent slice methods.
* I chose `write_clone_of_slice` and `write_copy_of_slice` since `clone` and `copy` are being used as objects here, whereas they're being used as actions in `clone_from_slice` and `copy_from_slice`.
The final "weird" thing I've done in this PR is remove a link to `Vec<T>` from `assume_init_drop` (both copies, since they're effectively copied docs), since there's no good way to link to `Vec` for something that can occur both on the page for `std/primitive.slice.html` and `std/vec/struct.Vec.html`, since the code here lives in libcore and can't use intra-doc-linking to mention `Vec`. (see: #121436)
The reason why this method shows up both on `Vec<T>` and `[T]` is because the `[T]` docs are automatically inlined on `Vec<T>`'s page, since it implements `Deref`. It's unfortunate that rustdoc doesn't have a way of dealing with this at the moment, but it is what it is, and it's a reasonable compromise for now.
Cleanup `suggest_binding_for_closure_capture_self` diag in borrowck
Mostly grammar fix/improvement, but also a small cleanup to use iterators instead of for loops for collecting into a vector.
this addresses review comments while:
- keeping the symmetry between the NLL and Polonius out of scope
precomputers
- keeping the unstable `calculate_borrows_out_of_scope_at_location`
function to avoid churn for consumers
we're in in the endgame now
set up the location-sensitive analysis end to end:
- stop recording inflowing loans and loan liveness in liveness
- replace location-insensitive liveness data with live loans computed by
reachability
- remove equivalence between polonius scopes and NLL scopes, and only
run one scope computation
in NLLs some locals are marked live at all points if one of their
regions escapes the function but that doesn't work in a flow-sensitive
setting like polonius
Eagerly collect mono items for non-generic closures
This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.
`-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in https://github.com/rust-lang/rust/pull/30900:
> Eager mode is meant to be used in conjunction with incremental compilation
> where a stable set of translation items is more important than a minimal
> one. Thus, eager mode will instantiate drop-glue for every drop-able type
> in the crate, even of no drop call for that type exists (yet). It will
> also instantiate default implementations of trait methods, something that
> otherwise is only done on demand.
Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.
And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
Rename `BitSet` to `DenseBitSet`
r? `@Mark-Simulacrum` as you requested this in https://github.com/rust-lang/rust/pull/134438#discussion_r1890659739 after such a confusion.
This PR renames `BitSet` to `DenseBitSet` to make it less obvious as the go-to solution for bitmap needs, as well as make its representation (and positives/negatives) clearer. It also expands the comments there to hopefully make it clearer when it's not a good fit, with some alternative bitsets types.
(This migrates the subtrees cg_gcc and clippy to use the new name in separate commits, for easier review by their respective owners, but they can obvs be squashed)
Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Slight tweak to output to remove unnecessary context as a drive-by.
Fix#134764.
add `-Zmin-function-alignment`
tracking issue: https://github.com/rust-lang/rust/issues/82232
This PR adds the `-Zmin-function-alignment=<align>` flag, that specifies a minimum alignment for all* functions.
### Motivation
This feature is requested by RfL [here](https://github.com/rust-lang/rust/issues/128830):
> i.e. the equivalents of `-fmin-function-alignment` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fmin-function-alignment_003dn), Clang does not support it) / `-falign-functions` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions), [Clang](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-falign-functions)).
>
> For the Linux kernel, the behavior wanted is that of GCC's `-fmin-function-alignment` and Clang's `-falign-functions`, i.e. align all functions, including cold functions.
>
> There is [`feature(fn_align)`](https://github.com/rust-lang/rust/issues/82232), but we need to do it globally.
### Behavior
The `fn_align` feature does not have an RFC. It was decided at the time that it would not be necessary, but maybe we feel differently about that now? In any case, here are the semantics of this flag:
- `-Zmin-function-alignment=<align>` specifies the minimum alignment of all* functions
- the `#[repr(align(<align>))]` attribute can be used to override the function alignment on a per-function basis: when `-Zmin-function-alignment` is specified, the attribute's value is only used when it is higher than the value passed to `-Zmin-function-alignment`.
- the target may decide to use a higher value (e.g. on x86_64 the minimum that LLVM generates is 16)
- The highest supported alignment in rust is `2^29`: I checked a bunch of targets, and they all emit the `.p2align 29` directive for targets that align functions at all (some GPU stuff does not have function alignment).
*: Only with `build-std` would the minimum alignment also be applied to `std` functions.
---
cc `@ojeda`
r? `@workingjubilee` you were active on the tracking issue
Add an InstSimplify for repetitive array expressions
I noticed in https://github.com/rust-lang/rust/pull/135068#issuecomment-2569955426 that GVN's implementation of this same transform was quite profitable on the deep-vector benchmark. But of course GVN doesn't run in unoptimized builds, so this is my attempt to write a version of this transform that benefits the deep-vector case and is fast enough to run in InstSimplify.
The benchmark suite indicates that this is effective.
Use llvm.memset.p0i8.* to initialize all same-bytes arrays
Similar to #43488
debug builds can now handle `0x0101_u16` and other multi-byte scalars that have all the same bytes (instead of special casing just `0`)
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:11:5
|
LL | object = &object2;
| ^^^^^^
|
note: the lint level is defined here
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:1:9
|
LL | #![deny(unused_assignments, unused_variables)]
| ^^^^^^^^^^^^^^^^^^
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object2(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument, trying to avoid an E0308.
```
error[E0308]: mismatched types
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:6:14
|
LL | fn change_object(mut object: &Object) {
| ------- expected due to this parameter type
LL | let object2 = Object;
LL | object = object2;
| ^^^^^^^ expected `&Object`, found `Object`
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument. We avoid suggesting `object = &object2;`, as that is less likely to be what was intended.
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Fix#134764.
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
Subtree sync for rustc_codegen_cranelift
This has a couple of changes that will conflict with https://github.com/rust-lang/rust/pull/134338.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Rollup of 7 pull requests
Successful merges:
- #132607 (Used pthread name functions returning result for FreeBSD and DragonFly)
- #134693 (proc_macro: Use `ToTokens` trait in `quote` macro)
- #134732 (Unify conditional-const error reporting with non-const error reporting)
- #135083 (Do not ICE when encountering predicates from other items in method error reporting)
- #135251 (Only treat plain literal patterns as short)
- #135320 (Fix typo in `#[coroutine]` gating error)
- #135321 (remove more redundant into() conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE when encountering predicates from other items in method error reporting
See the comments I left in the code and the test file.
Fixes https://github.com/rust-lang/rust/issues/124350
Unify conditional-const error reporting with non-const error reporting
This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead.
This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`.
r? fmease or reassign
Remove special-casing for argument patterns in MIR typeck (attempt to fix perf regression of #133858)
See [my comment](https://github.com/rust-lang/rust/pull/133858#issuecomment-2579029618) on #133858 for more information. This is just a guess as to what went wrong, and I haven't been able to get the profiler running locally, so I'll need a perf run to make sure this actually helps.
There's one test's stderr that suffers a bit, but this was just papering over the issue anyway. Making region errors point to the correct constraints in the presence of invariance/contravariance is a broader problem; the current way it's handled is mostly based on guesswork, luck, and hoping it works out. Properly handling that (somehow) would improve the test's stderr without the hack that this PR reverts.
Make sure to walk into nested const blocks in `RegionResolutionVisitor`
Fixes https://github.com/rust-lang/rust/issues/135306
I tried auditing the rest of the visitors that called `.visit_body`, and it seems like this is the only one that was missing it. I wonder if we should modify intravisit (specifcially, that `NestedBodyFilter` stuff) to make this less likely to happen, tho...
r? oli-obk
`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`
Tracking issue: #106764
Previously randomize-layout only used a deterministic shuffle based on the seed stored in an Adt's ReprOptions, meaning that `Foo<T>` and `Foo<U>` were shuffled by the same seed. This change adds a similar seed to each calculated LayoutData so that a struct can be randomized both based on the layout of its fields and its per-type seed.
Primitives start with simple seed derived from some of their properties. Though some types can no longer be distinguished at that point, e.g. usize and u64 will still be treated the same.
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix#135289.
Rollup of 3 pull requests
Successful merges:
- #134898 (Make it easier to run CI jobs locally)
- #135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible)
- #135261 (Account for identity substituted items in symbol mangling)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `lit_to_mir_constant` and `lit_to_const` infallible
My motivation for this change is just that it's annoying to check everywhere, especially since all but one call site was just ICEing on errors anyway right there.
They can still fail, but now just return an error constant instead of having the caller handle the error.
fixes#114317fixes#126182
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
`Ty::new` wasn't used anywhere outside this module
`Ty::new_adt` shouldn't ever be used for anything but adts. This hasn't caught any bugs, but seems good to check anyway
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.
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
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`
[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
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
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
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
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.
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.
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
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`
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
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.
`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`.
"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`.
The goal of this cleanup is to make it more apparent which feature gates
correspond to which typing rules, and which typing rules correspond to
what code. My intent is for calls to the "which typing rules do we
have?" functions to be replaced by comments (and edition checks, as
appropriate), but as long as we're experimenting with multiple rulesets,
this seemed to me to be the easiest to document and read. There's still
some nontrivial control flow, but I've added comments to try and make it
clearer.
There's some logic that looks like it could be de-duplicated across
different ways of matching against inherited references; however, the
duplication is intentional. Once we choose which rulesets we want, we
can make this more clever, but until then, my priorities are clarity and
ease of modification/extension. That said, I think the diagnostics could
use some work; factoring out commonalities there (and separating them
from the typing logic) would be ideal. I've opted not to include that
here both since it'd make this refactor less obvious and since it
affects test output.
Also, this doesn't get quite as fine-grained as Typing Rust Patterns, so
there's some instances where certain rules are conflated. I'd prefer to
minimize dead/untested codepaths for rulesets we're not interested in,
so as a compromise I've added comments wherever some aspect of the
typing rules is assumed from another. I'm not totally happy with it, but
I think it's at least better than plain checks against the feature gates
and edition.
If Rules 3 or 5 are adopted in any edition, we'll need to track the
`MutblCap` in all editions for macro hygiene purposes. Previously, the
check for whether to track it was conflated with the checks for whether
to apply Rules 3 and 5, so to make it a bit clearer, this always tracks
the `MutblCap`. If needed, we could check if Rules 3 or 5 are present in
any edition before tracking the `MutblCap`, but since it's not that much
more expensive to always track it, I've figured that's simplest.
My main concern with removing the checks is that it may not be clear
that the `MutblCap` is tracked for those specific purposes. To try and
mitigate this, I've made its doc comment a bit more precise regarding
the extent of how and why it's used.
This leaves the condition untouched on the `cap_to_weakly_not` call
needed for Rule 5, since it's only needed for that and it can affect
diagnostics.
As far as I can tell, the assignment removed here will never do
anything. `pat_info.max_ref_mutbl` starts at `MutblCap::Mut` for the
top-level pattern and is only changed if feature gates are enabled that
would result in the statement not being executed. Regardless of what new
pattern typing rules are adopted, I don't imagine we want to
conditionally reset `max_ref_mutbl` based on edition either, since it'd
have consequences for subpatterns in other editions.
This aims to reduce the complexity needed in the boolean logic for telling which
rules we're using to type patterns. If we still want the functionality this
removes, we can re-add it later, after some cleanup to pattern typing.
