-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 7 pull requests #120034
Commits on Jan 11, 2024
-
Enable Static Builds for FreeBSD
Enable crt-static for FreeBSD to enable statically compiled binaries.
Configuration menu - View commit details
-
Copy full SHA for adce3fd - Browse repository at this point
Copy the full SHA adce3fdView commit details
Commits on Jan 13, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 2de99ec - Browse repository at this point
Copy the full SHA 2de99ecView commit details
Commits on Jan 14, 2024
-
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.
Configuration menu - View commit details
-
Copy full SHA for d71f535 - Browse repository at this point
Copy the full SHA d71f535View commit details
Commits on Jan 15, 2024
-
Change return type of unstable
Waker::noop()
fromWaker
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. 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)
Configuration menu - View commit details
-
Copy full SHA for 7df054b - Browse repository at this point
Copy the full SHA 7df054bView commit details -
Remove unnecessary
let
s and borrowing fromWaker::noop()
usage.`Waker::noop()` now returns a `&'static Waker` reference, so it can be passed directly to `Context` creation with no temporary lifetime issue.
Configuration menu - View commit details
-
Copy full SHA for 219b00d - Browse repository at this point
Copy the full SHA 219b00dView commit details -
Configuration menu - View commit details
-
Copy full SHA for 9a8f117 - Browse repository at this point
Copy the full SHA 9a8f117View commit details -
Configuration menu - View commit details
-
Copy full SHA for 7052188 - Browse repository at this point
Copy the full SHA 7052188View commit details
Commits on Jan 16, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 290651b - Browse repository at this point
Copy the full SHA 290651bView commit details -
Configuration menu - View commit details
-
Copy full SHA for 3599c18 - Browse repository at this point
Copy the full SHA 3599c18View commit details -
Configuration menu - View commit details
-
Copy full SHA for 8bb1eae - Browse repository at this point
Copy the full SHA 8bb1eaeView commit details -
Configuration menu - View commit details
-
Copy full SHA for f1ee076 - Browse repository at this point
Copy the full SHA f1ee076View commit details -
Configuration menu - View commit details
-
Copy full SHA for f4e35c6 - Browse repository at this point
Copy the full SHA f4e35c6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 04a5ee6 - Browse repository at this point
Copy the full SHA 04a5ee6View commit details -
Configuration menu - View commit details
-
Copy full SHA for e12101c - Browse repository at this point
Copy the full SHA e12101cView commit details -
Rollup merge of rust-lang#119855 - rellerreller:freebsd-static, r=wes…
…leywiser Enable Static Builds for FreeBSD Enable crt-static for FreeBSD to enable statically compiled binaries.
Configuration menu - View commit details
-
Copy full SHA for 8512296 - Browse repository at this point
Copy the full SHA 8512296View commit details -
Rollup merge of rust-lang#119922 - nnethercote:fix-Diag-code-is_lint,…
… 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``
Configuration menu - View commit details
-
Copy full SHA for 6f13f87 - Browse repository at this point
Copy the full SHA 6f13f87View commit details -
Rollup merge of rust-lang#119978 - compiler-errors:async-closure-capt…
…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
Configuration menu - View commit details
-
Copy full SHA for f7c43dd - Browse repository at this point
Copy the full SHA f7c43ddView commit details -
Rollup merge of rust-lang#119984 - kpreid:waker-noop, r=dtolnay
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))
Configuration menu - View commit details
-
Copy full SHA for 89d4390 - Browse repository at this point
Copy the full SHA 89d4390View commit details -
Rollup merge of rust-lang#120020 - oli-obk:long_const_eval_err_taint,…
… 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
Configuration menu - View commit details
-
Copy full SHA for 26f922f - Browse repository at this point
Copy the full SHA 26f922fView commit details -
Rollup merge of rust-lang#120021 - lcnr:const-var-value, r=compiler-e…
…rrors don't store const var origins for known vars r? types
Configuration menu - View commit details
-
Copy full SHA for 31308c2 - Browse repository at this point
Copy the full SHA 31308c2View commit details -
Rollup merge of rust-lang#120032 - Nadrieril:fix-rustc_abi, r=Nilstrieb
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.
Configuration menu - View commit details
-
Copy full SHA for 5602018 - Browse repository at this point
Copy the full SHA 5602018View commit details