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

Remove StructuredDiag #127357

Merged
merged 3 commits into from
Jul 9, 2024
Merged

Remove StructuredDiag #127357

merged 3 commits into from
Jul 9, 2024

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jul 5, 2024

follow-up to #127319

This trait was an experiment that didn't pan out.

@rustbot
Copy link
Collaborator

rustbot commented Jul 5, 2024

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 5, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jul 5, 2024

HIR ty lowering was modified

cc @fmease

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 5, 2024
dcx: rustc_errors::DiagCtxtHandle<'a>,
level: rustc_errors::Level,
) -> Diag<'a, G> {
let msg = self.create_error_message();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to use translatable diagnostics, but that's something to do in a separate PR

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not required I guess

compiler/rustc_hir_typeck/messages.ftl Show resolved Hide resolved
compiler/rustc_hir_typeck/messages.ftl Show resolved Hide resolved
@@ -5,22 +5,22 @@ extern "C" {
fn main() {
unsafe {
printf(::std::ptr::null(), 0f32);
//~^ ERROR can't pass `f32` to variadic function
//~^ ERROR can't pass `f32` into variable arguments
Copy link
Member

@compiler-errors compiler-errors Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@workingjubilee yes C calls them "variable arguments" but I think it still calls the functions themselves "variadic functions".

A function that takes a variable number of arguments is called a variadic function.

(from https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html)

I think the latter is a more unique phrase (i.e. easier to google search lol) and we should keep it. Do you have an example of an error message that calls them "variable arguments"? I searched and couldn't really find anything mentioning either, since C error messages are kinda terse, but I did find this one that calls them "variadic functions":

https://godbolt.org/z/9c79z9j9Y

<source>:10:12: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string<char>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
    foo(1, s, 3);
           ^
1 error generated.
Compiler returned: 1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A niladic function would be one that takes zero arguments, a monadic function, one, a dyadic function, two, etc., by extension we arrive at variadic functions for a variable number of arguments. A function using C's ... is indeed a variadic function. However, your example function will be called with 1 fixed argument and an unknown number of variable arguments. It is still a variadic function if no variable arguments are passed at all. It can, in those fixed parameters, accept arguments of types prohibited in the variable arguments. Differing from C's terminology seems fine, but the previous message was incorrect in any case.

I realize this is extremely pedantic, but we really ought to be at least a few notches more pedantic about how we handle varargs.

The preference in C/C++ compilers handling erroneous cases seems to be literally just calling it ... which also seems fine, since that's what the programmer will actually be looking at. https://godbolt.org/z/81nEEEnjo

In file included from <source>:3:
<source>: In function 'void foo(int, ...)':
<source>:8:26: error: 'float' is promoted to 'double' when passed through '...' [-Werror]
    8 |     float f = va_arg(ap, float);
      |                          ^
<source>:8:26: note: (so you should pass 'double' not 'float' to 'va_arg')
<source>:8:26: note: if this code is reached, the program will abort
cc1plus: all warnings being treated as errors
Compiler returned: 1

Copy link
Member

@fmease fmease Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: Responding to errs.

To be fair, "can't pass `$ProblematicType` to variadic function" is imprecise (incorrect even, technically speaking) since it's legal to pass a value of $ProblematicType as an argument where the correp. param is "non-variable". E.g. 0f32 in f(0f32, x, y, z) is fine given e.g.fn f(_: f32, ...).

Still, the new phrasing does feel a bit uncommon.

Copy link
Member

@workingjubilee workingjubilee Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and this is an important distinction to preserve because some C ABIs are written in such a way that the way the arguments will be inspected in the callee function will be handled uniformly regardless of the number of arguments. In other words, they make it so ... is ABI-compatible with a hypothetical function with the same fixed arguments. So they deliberately conflate "variadic function" with "a function receiving any number of arguments" i.e. including a function with 1 fixed argument or 10 fixed arguments, because the ABIs are identical.

But others are not, and the way varargs are passed has nothing to do with the way other args are passed, so this is in fact completely incompatible. On those platforms, code which conflates these will explode, and some C libraries had to be rewritten for those platforms.

Copy link
Member

@fmease fmease left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me after addressing my comment in one way or another as well as err's comment.

@@ -138,6 +139,11 @@ hir_typeck_option_result_asref = use `{$def_path}::as_ref` to convert `{$expecte
hir_typeck_option_result_cloned = use `{$def_path}::cloned` to clone the value inside the `{$def_path}`
hir_typeck_option_result_copied = use `{$def_path}::copied` to copy the value inside the `{$def_path}`

hir_typeck_pass_to_variadic_function = can't pass `{$ty}` into variable arguments
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some options:

Suggested change
hir_typeck_pass_to_variadic_function = can't pass `{$ty}` into variable arguments
hir_typeck_pass_to_variadic_function = can't pass `{$ty}` into variadic arguments
Suggested change
hir_typeck_pass_to_variadic_function = can't pass `{$ty}` into variable arguments
hir_typeck_pass_to_variadic_function = can't pass `{$ty}` into `...`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefer either of these 👍

Copy link
Member

@fmease fmease Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case (esp. if we were to take the "`...`" one), we might also want to add a secondary highlight to the def site of the CVarArgs with a label to clear up any potential "surprises" (the user might not immediately realize that they were passing something to a CVarArgs list).

@fmease
Copy link
Member

fmease commented Jul 5, 2024

Oli, feel free to throw the user-visible changes to E0617 out of this PR and into a new one. I don't want to block this refactoring PR on diagnostic changes. Do however you please tho 🤷

@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 6, 2024
@oli-obk
Copy link
Contributor Author

oli-obk commented Jul 8, 2024

@bors r=fmease

@bors
Copy link
Contributor

bors commented Jul 8, 2024

📌 Commit 65598c8 has been approved by fmease

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 8, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 8, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#120248 (Make casts of pointers to trait objects stricter)
 - rust-lang#127355 (Mark format! with must_use hint)
 - rust-lang#127399 (Verify that allocations output by GVN are sufficiently aligned.)
 - rust-lang#127460 (clarify `sys::unix::fd::FileDesc::drop` comment)
 - rust-lang#127467 (bootstrap: once_cell::sync::Lazy -> std::sync::LazyLock)

Failed merges:

 - rust-lang#127357 (Remove `StructuredDiag`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Jul 8, 2024

☔ The latest upstream changes (presumably #127486) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 8, 2024
@oli-obk
Copy link
Contributor Author

oli-obk commented Jul 8, 2024

@bors r=fmease

@bors
Copy link
Contributor

bors commented Jul 8, 2024

📌 Commit af9ab1b has been approved by fmease

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 8, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 8, 2024
…llaumeGomez

Rollup of 4 pull requests

Successful merges:

 - rust-lang#126427 (Rewrite `intrinsic-unreachable`, `sepcomp-cci-copies`, `sepcomp-inlining` and `sepcomp-separate` `run-make` tests to rmake.rs)
 - rust-lang#127237 (Improve code of `run-make/llvm-ident`)
 - rust-lang#127325 (Migrate `target-cpu-native`,  `target-specs` and `target-without-atomic-cas` `run-make` tests to rmake)
 - rust-lang#127482 (Infer async closure signature from (old-style) two-part `Fn` + `Future` bounds)

Failed merges:

 - rust-lang#127357 (Remove `StructuredDiag`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Jul 9, 2024

⌛ Testing commit af9ab1b with merge cd3d98b...

@bors
Copy link
Contributor

bors commented Jul 9, 2024

☀️ Test successful - checks-actions
Approved by: fmease
Pushing cd3d98b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 9, 2024
@bors bors merged commit cd3d98b into rust-lang:master Jul 9, 2024
7 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jul 9, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (cd3d98b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.3% [2.3%, 2.3%] 1

Cycles

Results (primary -2.2%, secondary 2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.9% [2.9%, 2.9%] 2
Improvements ✅
(primary)
-2.2% [-2.4%, -1.9%] 5
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.2% [-2.4%, -1.9%] 5

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 702.448s -> 703.367s (0.13%)
Artifact size: 328.64 MiB -> 328.80 MiB (0.05%)

@oli-obk oli-obk deleted the structureddiag branch July 9, 2024 10:36
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? `@fmease`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? ``@fmease``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? ```@fmease```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? ````@fmease````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? `````@fmease`````
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 9, 2024
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on rust-lang#127357

r? `@fmease`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

7 participants