core: Remove panics from some `Layout` methods
`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!
As a result this commit makes the following tweaks:
* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
`Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
indicating that the function call couldn't panic wasn't quite right in that if
`alloc_size` becomes too large and if `align` is high enough it could indeed
cause a panic.
This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
Add error codes for libsyntax_ext
I intend to add error codes for `libsyntax_ext` as well. However, they cannot be used at stage 0 directly so I thought it might be possible to enable them at the stage 1 only so we can have access to the macros. However, the error code registration seems to not work this way. Currently I get the following error:
```
error: used diagnostic code E0660 not registered
--> libsyntax_ext/asm.rs:93:25
|
93 | span_err!(cx, sp, E0660, "malformed inline assembly");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error: used diagnostic code E0661 not registered
--> libsyntax_ext/asm.rs:151:33
|
151 | / span_err!(cx, sp, E0661,
152 | | "output operand constraint lacks '=' or '+'");
| |________________________________________________________________________________________^
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error: aborting due to 2 previous errors
error: Could not compile `syntax_ext`.
```
If anyone has an idea, I'd gladly take it. I'm trying to figure this out on my side as well. I also opened this PR to know if it was worth it to continue (maybe we don't want this?).
Anyway, any answer for both questions is very welcome!
cc @rust-lang/compiler
Add documentation links to the original type for various OS-specific
extension traits and normalize the language for introducing such traits.
Also, remove some outdated comments around the extension trait
definitions.
As discussed in #15536, the LLVM documentation incorrect described
overflowing f64->f32 casts as being undefined behavior. LLVM never
treated them as such, and the documentation has been adjusted in
https://reviews.llvm.org/rL329065. As such, this warning can now
be removed.
Closes#49622.
add target features when extracting and running doctests
When rendering documentation, rustdoc will happily load target features into the cfg environment from the current target, but fails to do this when doing anything with doctests. This would lead to situations where, thanks to https://github.com/rust-lang/rust/pull/48759, functions tagged with `#[target_feature]` couldn't run doctests, thanks to the automatic `#[doc(cfg(target_feature = "..."))]`.
Currently, there's no way to pass codegen options to rustdoc that will affect its rustc sessions, but for now this will let you use target features that come default on the platform you're targeting.
Fixes https://github.com/rust-lang/rust/issues/49723
Cleanup liballoc use statements
Some modules were still using the deprecated `allocator` module, use the
`alloc` module instead.
Some modules were using `super` while it's not needed.
Some modules were more or less ordering them, and other not, so the
latter have been modified to match the others.
Make --emit=metadata output metadata regardless of link
Fixes#40109. I'm not sure whether this condition was important here or not, but I can't see why it is required (removing it doesn't cause the error the comment warns about, so I'm assuming it's safe). If this is too heavy-handed, I can special-case on `OutputType::Metadata`.
r? @nrc
