Rollup of 9 pull requests #78589
Closed
Rollup of 9 pull requests #78589
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With this commit, the examples for exp_m1 would fail if x.exp() - 1.0 is used instead of x.exp_m1().
With this commit, the examples for ln_1p would fail if (x + 1.0).ln() is used instead of x.ln_1p().
When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
Co-authored-by: Camelid <camelidcamel@gmail.com>
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124
A simple `unwrap` fixes the issue.
Otherwise code like this
#![no_implicit_prelude]
fn main() {
::std::todo!();
::std::unimplemented!();
}
will fail to compile, which is unfortunate and presumably unintended.
This changes many invocations of `panic!` in a `macro_rules!` definition
to invocations of `$crate::panic!`, which makes the invocations hygienic.
Note that this does not make the built-in macro `assert!` hygienic.
* Switch a couple links over to intra-doc links * Clean up some formatting/typography
… r=KodrAus Add std::panic::panic_any. The discussion of rust-lang#67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any`, because it allows for any (`Any + Send`) type. _Tracking issue: #78500_
…ge, r=pnkfelix Implement rustc side of report-future-incompat cc rust-lang#71249 This is an alternative to @pnkfelix's initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch 😄 ). My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`. Several changes are made to support this feature: * The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`. * The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling). * A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`. * `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report). * `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data. Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future. I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself. cc @pnkfelix
make exp_m1 and ln_1p examples more representative of use With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
…u-se Qualify `panic!` as `core::panic!` in non-built-in `core` macros Fixes rust-lang#78333. ----- Otherwise code like this #![no_implicit_prelude] fn main() { ::std::todo!(); ::std::unimplemented!(); } will fail to compile, which is unfortunate and presumably unintended. This changes many invocations of `panic!` in a `macro_rules!` definition to invocations of `$crate::panic!`, which makes the invocations hygienic. Note that this does not make the built-in macro `assert!` hygienic.
…henkov Suggest calling associated `fn` inside `trait`s When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
Strip tokens from trait and impl items before printing AST JSON Fixes rust-lang#78510
rustc_llvm: unwrap LLVMMetadataRef before casting
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:
```
llvm-wrapper/RustWrapper.cpp:939:31: required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
1301 | struct is_base_of
| ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
from llvm-wrapper/LLVMWrapper.h:1,
from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
| ^~~~~~~~~~~~~~~~~~
```
[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124
A simple `unwrap` fixes the issue.
r? @eddyb
x.py setup: Create config.toml in the current directory, not the top-level directory See rust-lang#78509 for discussion. r? @pnkfelix cc @cuviper @Mark-Simulacrum
Use SOCK_CLOEXEC and accept4() on more platforms. This PR enables the use of `SOCK_CLOEXEC` and `accept4` on more platforms. ----- Android uses the linux kernel, so it should also support it. DragonflyBSD introduced them in 4.4 (December 2015): https://www.dragonflybsd.org/release44/ FreeBSD introduced them in 10.0 (January 2014): https://wiki.freebsd.org/AtomicCloseOnExec Illumos introduced them in a commit in April 2013, not sure when it was released. It is quite possible that is has always been in Illumos: illumos/illumos-gate@5dbfd19 https://illumos.org/man/3socket/socket https://illumos.org/man/3socket/accept4 NetBSD introduced them in 6.0 (Oktober 2012) and 8.0 (July 2018): https://man.netbsd.org/NetBSD-6.0/socket.2 https://man.netbsd.org/NetBSD-8.0/accept.2 OpenBSD introduced them in 5.7 (May 2015): https://man.openbsd.org/socket https://man.openbsd.org/accept
|
@bors r+ rollup=never p=5 |
|
📌 Commit defae8d has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit defae8d with merge cfbb7a88facae19e60095641ee963f38c3aed98f... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
panic!ascore::panic!in non-built-incoremacros #78343 (Qualifypanic!ascore::panic!in non-built-incoremacros)fninsidetraits #78420 (Suggest calling associatedfninsidetraits)Failed merges:
r? @ghost