Add some missing `#[must_use]` to some `f{32,64}` operations
This PR adds `#[must_use]` to the following methods:
- `f32::recip`
- `f32::max`
- `f32::min`
- `f32::maximum`
- `f32::minimum`
and their equivalents in `f64`.
These methods all produce a new value without modifying the original and so are pointless to call without using the result.
Add note about non_exhaustive to variant_count
Since `variant_count` isn't returning something opaque, I thought it makes sense to explicitly call out that its return value may change for some enums.
cc #73662
Consolidate checking for msvc when generating debuginfo
If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.
I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.
r? ``@michaelwoerister``
This PR is not urgent so please don't let it interrupt your holidays! 🎄🎁
Remove &self from PrintState::to_string
The point of `PrintState::to_string` is to create a `State` and evaluate the caller's closure on it:
e9fbe79292/compiler/rustc_ast_pretty/src/pprust/state.rs (L868-L872)
Making the caller *also* construct and pass in a `State`, which is then ignored, was confusing.
Implement `TryFrom<char>` for `u8`
Previously suggested in https://github.com/rust-lang/rfcs/issues/2854.
It makes sense to have this since `char` implements `From<u8>`. Likewise `u32`, `u64`, and `u128` (since #79502) implement `From<char>`.
Previously suggested in https://github.com/rust-lang/rfcs/issues/2854.
It makes sense to have this since `char` implements `From<u8>`. Likewise
`u32`, `u64`, and `u128` (since #79502) implement `From<char>`.
If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.
I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.
Rollup of 8 pull requests
Successful merges:
- #91055 (return the correct type for closures in `type_of`)
- #92207 (Delay remaining `span_bug`s in drop elaboration)
- #92417 (Fix spacing and ordering of words in pretty printed Impl)
- #92504 (Exit nonzero on rustc -Wall)
- #92559 (RustWrapper: adapt to new AttributeMask API)
- #92589 (Break the loop)
- #92607 (rustc_metadata: Some minor cleanups and optimizations)
- #92620 (Remove unused `ExtendDefault` struct)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Break the loop
A missing break statement lead to an infinite loop in bootstrap.py.
I also added a short sleep so it's not constantly running at 100%. But I can remove that if it's not wanted.
Fixes#76661
RustWrapper: adapt to new AttributeMask API
Upstream LLVM change 9290ccc3c1a1 migrated attribute removal to use
AttributeMask instead of AttrBuilder, so we need to follow suit here.
r? ``@nagisa`` cc ``@nikic``
Exit nonzero on rustc -Wall
Previously `rustc -Wall /dev/null` would print a paragraph explaining that `-Wall` is not a thing in Rust, but would then exit 0. I believe exiting 0 is not the right behavior. For something like `rustc --version` or `rustc --help` or `rustc -C help` the user is requesting rustc to print some information; rustc prints that information and exits 0 because what the user requested has been accomplished. In the case of `rustc -Wall path/to/main.rs`, I don't find it correct to conceptualize this as "the user requested rustc to print information about the fact that Wall doesn't exist". The user requested a particular thing, and despite rustc knowing what they probably meant and informing them about that, the thing they requested has *not* been accomplished. Thus a nonzero exit code is needed.
Fix spacing and ordering of words in pretty printed Impl
Follow-up to #92238 fixing one of the FIXMEs.
```rust
macro_rules! repro {
($item:item) => {
stringify!($item)
};
}
fn main() {
println!("{}", repro!(impl<T> Struct<T> {}));
println!("{}", repro!(impl<T> const Trait for T {}));
}
```
Before: `impl <T> Struct<T> {}`
After: `impl<T> Struct<T> {}`
Before: `impl const <T> Trait for T {}` 😿
After: `impl<T> const Trait for T {}`
Delay remaining `span_bug`s in drop elaboration
This follows changes from #67967 and converts remaining `span_bug`s into
delayed bugs, since for const items drop elaboration might be executed
on a MIR which failed borrowck.
Fixes#81708.
Fixes#91816.
return the correct type for closures in `type_of`
A bit unhappy about the way `typeck::check_crate` works rn. Would have preferred to not change `CollectItemTypesVisitor` in this way.
r? ``@nikomatsakis``
I had the epiphany that now that fragments are "semantic" -- rather than
just strings -- they fill the role that used to be handled by the side
channel. I think I may be able to get rid of the other uses of the side
channel using this technique too.
Rollup of 7 pull requests
Successful merges:
- #92058 (Make Run button visible on hover)
- #92288 (Fix a pair of mistyped test cases in `std::net::ip`)
- #92349 (Fix rustdoc::private_doc_tests lint for public re-exported items)
- #92360 (Some cleanups around check_argument_types)
- #92389 (Regression test for borrowck ICE #92015)
- #92404 (Fix font size for [src] links in headers)
- #92443 (Rustdoc: resolve associated traits for non-generic primitive types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
cg: split dwarf for crate dependencies
Fixes#81024.
- In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split, respectively.
On Unix, `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it.
In the initial implementation of Split DWARF, split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode, sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However, both split and single modes could be packaged or not, the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file).
In the first commit of this PR, I re-introduce a `-Z split-dwarf-kind` flag, which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked).
- Split DWARF packaging requires all of the object files to exist, including those in dependencies. ~~Therefore, the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place), then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single`, and dwarf objects if `SplitDwarfKind::Split`.~~
~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223, I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach.
- ~~There's still a dependency on `llvm-dwp` after this change, which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally, Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change, it depends whether or not switching away from `llvm-dwp` later would break any guarantees, or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867.
r? `@nagisa`
cc `@alexcrichton`
