Rollup of 8 pull requests
Successful merges:
- #64726 (rewrite documentation for unimplemented! to clarify use)
- #65040 (syntax: more cleanups in item and function signature parsing)
- #65046 (Make `Cell::new` method come first in documentation)
- #65098 (Add long error explanation for E0561)
- #65150 (Suggest dereferencing boolean reference when used in 'if' or 'while')
- #65154 (Fix const generic arguments not displaying in types mismatch diagnostic)
- #65181 (fix bug in folding for constants)
- #65187 (use 'invalid argument' for vxWorks)
Failed merges:
- #65179 (Add long error explanation for E0567)
r? @ghost
fix bug in folding for constants
These was a bug in the folding for constants that caused it to overlook bound regions. This branch includes some other little things that I did while trying to track the bug down.
r? @oli-obk
Make `Cell::new` method come first in documentation
Methods to create a thing usually comes first in `std` documentation, and `Cell` has been an exception. Also, `T: Copy` specialized methods should not be on top of the page. (This had led me to miss that most of its methods are not bounded by `Copy`...)
rewrite documentation for unimplemented! to clarify use
The current docs for `unimplemented!` seem to miss the point of this macro.
> This can be useful if you are prototyping and are just looking to have your code type-check, or if you're implementing a trait that requires multiple methods, and you're only planning on using one of them.
You could also return a `()` if you just want your code to type-check.
I think `unimplemented!` is useful for when you want your program to exit when it reaches an unimplemented area.
I rewrote the explanation and gave examples of both forms of this macro that I think clarify its use a little better.
Only add sanitizer runtimes when linking an executable (#64629).
This change modifies the code to only add sanitizer runtimes if we are linking an executable, as those runtimes should never be part of libraries. I successfully compiled `mozilla-central` with ASan using this patch.
Update reference
- Add macros in extern blocks and new proc-macro support.
- Update for "modern" `meta` matcher.
- Update await desugaring after rust-lang/rust#64292
remove event that causes panics in measureme tools
the measureme tools summarize and crox do not alow a event to go out of scope of the parent event
codegen_and_optimize_crate ends after the codegen_crate event
r? @wesleywiser
cc @michaelwoerister @Mark-Simulacrum
Add feature gate for raw_dylib.
This PR adds the feature gate for RFC 2627 (https://github.com/rust-lang/rust/issues/58713). It doesn't contain the actual functionality.
Add I'm not sure whether i did it correctly, since this is the first time i did this.
r? @Centril
Add support for `const unsafe? extern fn`
This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code.
Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime.
Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary.
This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
Tracking issue: https://github.com/rust-lang/rust/issues/64926.
- 771c5d10cf944bf7d221f5d6cb7abd2a06c400e4 Add macros in extern blocks and new proc-macro support.
- 8caabd62ef5fbe99e6be6aa9e76f55bbb8433d95 Update for "modern" `meta` matcher.
- 1b44947d36ccf7eba2b3bd245769eff68abf6d4d Update await desugaring after rust-lang/rust#64292