Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make error message for missing fields with .. and without .. more consistent #139024

Merged
merged 1 commit into from
Apr 8, 2025

Conversation

compiler-errors
Copy link
Member

When .. is not present, we say "missing field bar in initializer", but when it is present we say "missing mandatory field bar". I don't see why the primary error message should change, b/c the root cause is the same.

Let's harmonize these error messages and instead use a label to explain that .. is required b/c it's not defaulted.

r? estebank

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 27, 2025
@compiler-errors
Copy link
Member Author

r? compiler

@rustbot rustbot assigned lcnr and unassigned estebank Apr 7, 2025
@compiler-errors compiler-errors force-pushed the tweak-default-value-err branch from 967ea6a to 250b848 Compare April 7, 2025 20:45
@compiler-errors
Copy link
Member Author

@bors r=lcnr rollup

@bors
Copy link
Collaborator

bors commented Apr 7, 2025

📌 Commit 250b848 has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 7, 2025
Zalathar added a commit to Zalathar/rust that referenced this pull request Apr 8, 2025
…e-err, r=lcnr

Make error message for missing fields with `..` and without `..` more consistent

When `..` is not present, we say "missing field `bar` in initializer", but when it is present we say "missing mandatory field `bar`". I don't see why the primary error message should change, b/c the root cause is the same.

Let's harmonize these error messages and instead use a label to explain that `..` is required b/c it's not defaulted.

r? estebank
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 8, 2025
…errors

Rollup of 19 pull requests

Successful merges:

 - rust-lang#138676 (Implement overflow for infinite implied lifetime bounds)
 - rust-lang#139024 (Make error message for missing fields with `..` and without `..` more consistent)
 - rust-lang#139098 (Tell LLVM about impossible niche tags)
 - rust-lang#139124 (compiler: report error when trait object type param reference self)
 - rust-lang#139321 (Update to new rinja version (askama))
 - rust-lang#139346 (Don't construct preds w escaping bound vars in `diagnostic_hir_wf_check`)
 - rust-lang#139386 (make it possible to use stage0 libtest on compiletest)
 - rust-lang#139421 (Fix trait upcasting to dyn type with no principal when there are projections)
 - rust-lang#139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`)
 - rust-lang#139476 (rm `RegionInferenceContext::var_infos`)
 - rust-lang#139481 (Add job summary links to post-merge report)
 - rust-lang#139485 (compiletest: Stricter parsing for diagnostic kinds)
 - rust-lang#139490 (Update some comment/docs related to "extern intrinsic" removal)
 - rust-lang#139491 (Update books)
 - rust-lang#139496 (Revert r-a changes of rust-lang#139455)
 - rust-lang#139500 (document panic behavior of Vec::resize and Vec::resize_with)
 - rust-lang#139501 (Fix stack overflow in exhaustiveness due to recursive HIR opaque hidden types)
 - rust-lang#139504 (add missing word in doc comment)
 - rust-lang#139507 (compiletest: Trim whitespace from environment variable names)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 8, 2025
Rollup of 10 pull requests

Successful merges:

 - rust-lang#138676 (Implement overflow for infinite implied lifetime bounds)
 - rust-lang#139024 (Make error message for missing fields with `..` and without `..` more consistent)
 - rust-lang#139098 (Tell LLVM about impossible niche tags)
 - rust-lang#139124 (compiler: report error when trait object type param reference self)
 - rust-lang#139321 (Update to new rinja version (askama))
 - rust-lang#139346 (Don't construct preds w escaping bound vars in `diagnostic_hir_wf_check`)
 - rust-lang#139386 (make it possible to use stage0 libtest on compiletest)
 - rust-lang#139421 (Fix trait upcasting to dyn type with no principal when there are projections)
 - rust-lang#139464 (Allow for reparsing failure when reparsing a pasted metavar.)
 - rust-lang#139490 (Update some comment/docs related to "extern intrinsic" removal)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 6257825 into rust-lang:master Apr 8, 2025
6 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 8, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 8, 2025
Rollup merge of rust-lang#139024 - compiler-errors:tweak-default-value-err, r=lcnr

Make error message for missing fields with `..` and without `..` more consistent

When `..` is not present, we say "missing field `bar` in initializer", but when it is present we say "missing mandatory field `bar`". I don't see why the primary error message should change, b/c the root cause is the same.

Let's harmonize these error messages and instead use a label to explain that `..` is required b/c it's not defaulted.

r? estebank
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants