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

Rollup of 7 pull requests #120034

Closed
wants to merge 21 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

rellerreller and others added 21 commits January 11, 2024 15:26
Enable crt-static for FreeBSD to enable statically compiled binaries.
`Diagnostic::code` has the type `DiagnosticId`, which has `Error` and
`Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be
redundant w.r.t. `Diagnostic::code`.

Seems simple. Except it's possible for a lint to have an error code, in
which case its `code` field is recorded as `Error`, and `is_lint` is
required to indicate that it's a lint. This is what happens with
`derive(LintDiagnostic)` lints. Which means those lints don't have a
lint name or a `has_future_breakage` field because those are stored in
the `DiagnosticId::Lint`.

It's all a bit messy and confused and seems unintentional.

This commit:
- removes `DiagnosticId`;
- changes `Diagnostic::code` to `Option<String>`, which means both
  errors and lints can straightforwardly have an error code;
- changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a
  new type containing a lint name and a `has_future_breakage` bool, so
  all lints can have those, error code or not.
The advantage of this is that it does not need to be assigned to a
variable to be used in a `Context` creation, which is the most common
thing to want to do with a noop waker.

If an owned noop waker is desired, it can be created by cloning, but the
reverse is harder. Alternatively, both versions could be provided, like
`futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but
that seems to me to be API clutter for a very small benefit, whereas
having the `&'static` reference available is a large benefit.

Previous discussion on the tracking issue starting here:
rust-lang#98286 (comment)
`Waker::noop()` now returns a `&'static Waker` reference, so it can be
passed directly to `Context` creation with no temporary lifetime issue.
…leywiser

Enable Static Builds for FreeBSD

Enable crt-static for FreeBSD to enable statically compiled binaries.
… r=oli-obk

Rework how diagnostic lints are stored.

`Diagnostic::code` has the type `DiagnosticId`, which has `Error` and
`Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be
redundant w.r.t. `Diagnostic::code`.

Seems simple. Except it's possible for a lint to have an error code, in
which case its `code` field is recorded as `Error`, and `is_lint` is
required to indicate that it's a lint. This is what happens with
`derive(LintDiagnostic)` lints. Which means those lints don't have a
lint name or a `has_future_breakage` field because those are stored in
the `DiagnosticId::Lint`.

It's all a bit messy and confused and seems unintentional.

This commit:
- removes `DiagnosticId`;
- changes `Diagnostic::code` to `Option<String>`, which means both
  errors and lints can straightforwardly have an error code;
- changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a
  new type containing a lint name and a `has_future_breakage` bool, so
  all lints can have those, error code or not.

r? ``@oli-obk``
…ures, r=oli-obk

Move async closure parameters into the resultant closure's future eagerly

Move async closure parameters into the closure's resultant future eagerly.

Before, we used to desugar `async |p1, p2, ..| { body }` as `|p1, p2, ..| { || async { body } }`. Now, we desugar the above like `|p1, p2, ..| { async move { let p1 = p1; let p2 = p2; ... body } }`. This mirrors the same desugaring that `async fn` does with its parameter types, and the compiler literally uses the same code via a shared helper function.

This removes the necessity for E0708, since now expressions like `async |x: i32| { x }` will not give you confusing borrow errors.

This does *not* fix the case where async closures have self-borrows. This will come with a general implementation of async closures, which is still in the works.

r? oli-obk
Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.

The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. It also avoids unnecessarily executing the dynamically dispatched drop function when the noop waker is dropped.

If an owned noop waker is desired, it can be created by cloning, but the reverse is harder to do since it requires declaring a constant. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large reduction in boilerplate.

[Previous discussion on the tracking issue starting here](rust-lang#98286 (comment))
… r=compiler-errors

Gracefully handle missing typeck information if typeck errored

fixes rust-lang#116893

I created some logs and the typeck of `fn main` is exactly the same, no matter whether the constant's body is what it is, or if it is replaced with `panic!()`. The latter will cause the ICE not to be emitted though. The reason for that is that we abort compilation if *errors* were emitted, but not if *lint errors* were emitted. This took me way too long to debug, and is another reason why I would have liked rust-lang/compiler-team#633
…rrors

don't store const var origins for known vars

r? types
Fix `rustc_abi` build on stable

rust-lang#119446 broke the ability of `rustc_abi` to build on stable, which is required by rust-analyzer. This fixes it.
@rustbot rustbot added A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 16, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jan 16, 2024

📌 Commit 5602018 has been approved by matthiaskrgr

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 Jan 16, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 17, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#119855 (Enable Static Builds for FreeBSD)
 - rust-lang#119922 (Rework how diagnostic lints are stored.)
 - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly)
 - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.)
 - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored)
 - rust-lang#120021 (don't store const var origins for known vars)
 - rust-lang#120032 (Fix `rustc_abi` build on stable)

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

bors commented Jan 17, 2024

⌛ Testing commit 5602018 with merge 06f315f...

@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
Submodule path 'src/doc/rust-by-example': checked out 'ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d'
From https://github.com/rust-lang/rustc-dev-guide
 * branch            4af29d1a7f64f88a36539662c6a84fe1fbe6cde1 -> FETCH_HEAD
Submodule path 'src/doc/rustc-dev-guide': checked out '4af29d1a7f64f88a36539662c6a84fe1fbe6cde1'
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
##[error]Process completed with exit code 143.

@bors
Copy link
Contributor

bors commented Jan 17, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 17, 2024
@matthiaskrgr
Copy link
Member Author

@bors retry

@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 Jan 17, 2024
@bors
Copy link
Contributor

bors commented Jan 17, 2024

⌛ Testing commit 5602018 with merge 05c0a04...

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 17, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#119855 (Enable Static Builds for FreeBSD)
 - rust-lang#119922 (Rework how diagnostic lints are stored.)
 - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly)
 - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.)
 - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored)
 - rust-lang#120021 (don't store const var origins for known vars)
 - rust-lang#120032 (Fix `rustc_abi` build on stable)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [coverage-run] tests/coverage/closure_macro_async.rs stdout ----
diff of coverage:

15    LL|       |
16    LL|       |macro_rules! on_error {
17    LL|       |    ($value:expr, $error_message:expr) => {
-    LL|       |        $value.or_else(|e| { // FIXME(85000): no coverage in closure macros
+    LL|       |        $value.or_else(|e| {
+    LL|       |            // FIXME(85000): no coverage in closure macros
19    LL|       |            let message = format!($error_message, e);
20    LL|       |            if message.len() > 0 {
21    LL|       |                println!("{}", message);

The actual coverage differed from the expected coverage.
The actual coverage differed from the expected coverage.
Actual coverage saved to /checkout/obj/build/aarch64-unknown-linux-gnu/test/coverage/closure_macro_async.coverage-run/closure_macro_async.coverage

error: 1 errors occurred comparing coverage output.
status: exit status: 0
status: exit status: 0
command: "/checkout/obj/build/aarch64-unknown-linux-gnu/llvm/build/bin/llvm-cov" "show" "--format=text" "--show-line-counts-or-regions" "--Xdemangler" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage0-tools-bin/rust-demangler" "--instr-profile" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/coverage/closure_macro_async.coverage-run/default.profdata" "--object" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/coverage/closure_macro_async.coverage-run/a"
--- stdout -------------------------------
    1|       |#![feature(coverage_attribute)]
    2|       |#![feature(noop_waker)]
    3|       |// edition: 2018
    4|       |
    5|       |macro_rules! bail {
    6|       |    ($msg:literal $(,)?) => {
    7|       |        if $msg.len() > 0 {
    8|       |            println!("no msg");
   10|       |            println!($msg);
   11|       |        }
   12|       |        return Err(String::from($msg));
   13|       |    };
   13|       |    };
   14|       |}
   15|       |
   16|       |macro_rules! on_error {
   17|       |    ($value:expr, $error_message:expr) => {
   18|       |        $value.or_else(|e| {
   19|       |            // FIXME(85000): no coverage in closure macros
   20|       |            let message = format!($error_message, e);
   21|       |            if message.len() > 0 {
   22|       |                println!("{}", message);
   23|       |                Ok(String::from("ok"))
   24|       |            } else {
   25|       |                bail!("error");
   27|       |        })
   28|       |    };
   29|       |}
   30|       |
   30|       |
   31|      1|fn load_configuration_files() -> Result<String, String> {
   32|      1|    Ok(String::from("config"))
   33|      1|}
   34|       |
   35|      1|pub async fn test() -> Result<(), String> {
   36|      1|    println!("Starting service");
   37|      1|    let config = on_error!(load_configuration_files(), "Error loading configs: {}")?;
   38|       |
   38|       |
   39|      1|    let startup_delay_duration = String::from("arg");
   40|      1|    let _ = (config, startup_delay_duration);
   42|      1|}
   43|       |
   43|       |
   44|       |#[coverage(off)]
   45|       |fn main() {
   46|       |    executor::block_on(test()).unwrap();
   47|       |}
   48|       |
   49|       |mod executor {
   50|       |    use core::future::Future;
   51|       |    use core::pin::pin;
   52|       |    use core::task::{Context, Poll, Waker};
   53|       |
   54|       |    #[coverage(off)]
   55|       |    pub fn block_on<F: Future>(mut future: F) -> F::Output {
   56|       |        let mut future = pin!(future);
   57|       |        let mut context = Context::from_waker(Waker::noop());
   59|       |        loop {
   59|       |        loop {
   60|       |            if let Poll::Ready(val) = future.as_mut().poll(&mut context) {
   61|       |                break val;
   63|       |        }
   64|       |    }
   65|       |}
------------------------------------------

@bors
Copy link
Contributor

bors commented Jan 17, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 17, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-dr3hbb2 branch March 16, 2024 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic rollup A PR which is a rollup 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. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.