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.
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>
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
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.
Matthias Krüger