Lazy normalization of constants (Reprise)
Continuation of #67890 by @skinny121.
Initial implementation of #60471 for constants.
Perform normalization/evaluation of constants lazily, which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]`, by default constants are still evaluated eagerly as there are currently.
Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later, avoiding cycle errors.
Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs.
r? @nikomatsakis
fixes#71922, fixes#71986
Support coercion between (FnDef | Closure) and (FnDef | Closure)
Fixes#46742, fixes#48109
Inject `Closure` into the `FnDef x FnDef` coercion special case, which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible, where closures should be **non-capturing**.
abort_internal is safe
`sys::abort_internal` is stably exposed as a safe function. Forward that assumption "inwards" to the `sys` module by making the function itself safe, too.
This corresponds to what https://github.com/rust-lang/rust/pull/72204 did for the intrinsic. We should probably wait until that lands because some of the intrinsic calls in this PR might then need adjustments.
use the new interface to initialize conditional variables
HermitCore introduce a new interface to intialize conditional variables.
Consequently, minor changes are required to support this interface.
make offset must_use
https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset:
> At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer, which gets dropped silently if you don't use it. Unlike for example Result, which is must_use annotated.
This PR only adds `offset`, because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning.
r? @rust-lang/libs
move borrow-of-packed-field unsafety check out of loop
Looks like during the place refactoring, this code somehow got into this loop even though it does not actually depend on the loop variables.
https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset:
> At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer, which gets dropped silently if you don't use it. Unlike for example Result, which is must_use annotated.
Disallow forbidden usage of non-ascii identifiers.
Part of RFC2457, this tightens allowed identifiers back to ascii only in two situations.
r? @petrochenkov
make abort intrinsic safe, and correct its documentation
Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation:
```
// On Unix-like platforms, libc::abort will unregister signal handlers
// including the SIGABRT handler, preventing the abort from being blocked, and
// fclose streams, with the side effect of flushing them so libc buffered
// output will be printed. Additionally the shell will generally print a more
// understandable error message like "Abort trap" rather than "Illegal
// instruction" that intrinsics::abort would cause, as intrinsics::abort is
// implemented as an illegal instruction.
```
Rename lint `identity_conversion` to `useless_conversion`
Lint name `identity_conversion` was misleading, so this PR renames it to `useless_conversion`.
As decision has not really came up in the issue comments, this PR will probably need discussion.
fixes#3106
changelog: Rename lint `identity_conversion` to `useless_conversion`
