Stabilize assoc_int_consts associated int/float constants
The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325.
* Stabilize all constants under the `assoc_int_consts` feature flag.
* Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred.
* Update documentation examples to use new constants.
* Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway.
r? @LukasKalbertodt
Invoke OptimizerLastEPCallbacks in PreLinkThinLTO
The default ThinLTO pre-link pipeline does not include optimizer last
extension points. Thus, when using the new LLVM pass manager & ThinLTO
& sanitizers on any opt-level different from zero, the sanitizer
function passes would be omitted from the pipeline.
Add optimizer last extensions points manually to the pipeline, but guard
registration with stage check in the case this behaviour changes in the
future.
cleanup more iterator usages (and other things)
* Improve weird formatting by moving comment inside else-code block.
* Use .any(x) instead of .find(x).is_some() on iterators.
* Use .nth(x) instead of .skip(x).next() on iterators.
* Simplify conditions like x + 1 <= y to x < y
* Use let instead of match to get value of enum with single variant.
miri engine: turn some debug_assert into assert
@eddyb said to avoid debug assertions in rustc. These checks here look like they are probably not too expensive. Cc @oli-obk
encode `;` stmt without expr as `StmtKind::Empty`
Instead of encoding `;` statements without a an expression as a tuple in AST, encode it as `ast::StmtKind::Empty`.
r? @petrochenkov
PR #69562, which fixed a bug that was causing clippy to ICE, passed the
place for the *result* of `Rvalue::Discriminant` instead of the
*operand* to `apply_discriminant_switch_effect`. As a result, no effect
was applied at all, and we lost the perf benefits from marking
inactive enum variants as uninitialized.
Improve linking of crates with circular dependencies
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:
* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.
This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.
The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.
Verified using test case from #69368.
Polonius: update `polonius-engine` to 0.12.0
Since @albins won't have the time to finish up #68993 for a while, I'll take care of the trivial remaining tasks (rebasing, taking care of tidy/rustfmt).
I'll r? @nikomatsakis since they're assigned to #68993, but have actually [already reviewed it pre-rebase](https://github.com/rust-lang/rust/pull/68993#issuecomment-586413089).
When CI passes: I'll notify bors and close#68993, since this PR supersedes it.
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:
* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.
This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.
The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.
Verified using test case from 69368.
more cleanups
* use starts_with() instead of chars().next() == Some(x)
* use subsec_micros() instead of subsec_nanos() / 1000
* use for (idx, item) in iter.enumerate() instead of manually counting loop iterations with variables
* use values() or keys() respectively when iterating only over keys or values of maps.
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closesrust-lang/wg-allocators#17
Additionally verify that the current implementation of LLVM version
check (which uses lexicographic ordering) is good enough to exclude
versions before LLVM 9, where the new LLVM pass manager is unsupported.
The default ThinLTO pre-link pipeline does not include optimizer last
extension points. Thus, when using the new LLVM pass manager & ThinLTO
& sanitizers on any opt-level different from zero, the sanitizer
function passes would be omitted from the pipeline.
Add optimizer last extensions points manually to the pipeline, but guard
registration with stage check in the case this behaviour changes in the
future.
Remove experimental chalk option
As suggested by @nikomatsakis [here](https://github.com/rust-lang/rust/pull/68807#issuecomment-583339932).
The current version of chalk used by the experimental `-Zchalk` flag is [v0.9.0, which is over a year old](https://crates.io/crates/chalk-engine). Since v0.9.0, chalk has seen [a lot of further development](https://github.com/rust-lang/chalk/compare/41dfe13...master), and the intent is to eventually upgrade rustc to use a more recent chalk.
However, it will take a decent chunk of effort to upgrade the current experimental chalk support, and it is currently [blocking at least some PRs](https://github.com/rust-lang/rust/pull/68807) due to chalk:0.9.0's use of unstable features. So for the interim until the next chalk release and experimental rustc integration, we remove the chalk-specific code from rustc.
