Implement saturating_abs() and saturating_neg() functions for signed integer types
Similar to wrapping_abs() / wrapping_neg() functions but saturating at the numeric bounds instead of wrapping around. Complements the existing set of functions with saturation mechanics.
cc #59983
It looks like the `OutputType::Metadata` kind in the compiler was
misclassified in #38571 long ago by accident as incompatible with
codegen units and a single output file. This means that if you emit both
a linkable artifact and metadata it silently turns off multiple codegen
units unintentionally!
This commit corrects the situation to ensure that if `--emit metadata`
is used it doesn't implicitly disable multiple codegen units. This will
ensure we don't accidentally regress compiler performance when striving
to implement pipelined compilation!
Similar to wrapping_abs() / wrapping_neg() functions but saturating at
the numeric bounds instead of wrapping around. Complements the existing
set of functions with saturation mechanics.
submodules: update clippy from 9897442f to 8c0e038f
Should fix clippy/rls toolstate breakage
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
r? @oli-obk
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
Reexport IntErrorKind in std
Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?).
Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue.
Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.
Fix#58270, fix off-by-one error in error diagnostics.
This fixes#58270 by checking if two diagnostics overlap completely when we're calculating the line offset for each message.
Add codegen test for PGO instrumentation.
This PR adds a codegen test that makes sure that LLVM actually generates instrumentation code when we enable PGO instrumentation in `rustc`.
The second commit updates a test case to the new commandline option syntax introduced in #59874. Without the fix the test still works, but it confusingly creates a directory called `test.profraw`, which usually is the name of the _file_ where profiling data is collected.
tweak unresolved label suggestion
Only suggest label names in the same hygiene context, and use a
structured suggestion.
Question for reviewer: Is this the right way to check for label hygiene?
MIR generation cleanup
* Handle the case where the body of a constant is a subtype of the type of the constant (see `mir_static_subtype.rs`).
* Move the evaluation of `ExprKind::Use` into `into.rs`, saving an unnecessary copy.
HirIdification: rework Map
The next iteration of HirIdification (#57578).
- remove `NodeId` from `Entry`
- change `Map::map` to an `FxHashMap<HirId, Entry>`
- base the `NodeId` `Map` methods on `HirId` ones (reverses the current state)
- HirIdify `librustdoc` a little bit (some `NodeId` `Map` methods were converted to work on `HirId`s)
The second change might have performance implications, so I'd do a perf run to be sure it's fine; it simplifies the codebase and shouldn't have an impact as long as the `Map` searches are cached (which is now possible thanks to using `HirId`s).
r? @Zoxc
