When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
This commit adds a compiler option which allows a user to force the
addition of unwind tables. Unwind tables cannot be disabled on targets
that require them for correctness, or when using `-C panic=unwind`.
This commit finishes work first pioneered in #70458 and started in #71528.
The `-C bitcode-in-rlib` option, which has not yet reached stable, is
renamed to `-C embed-bitcode` since that more accurately reflects what
it does now anyway. Various tests and such are updated along the way as
well.
This'll also need to be backported to the beta channel to ensure we
don't accidentally stabilize `-Cbitcode-in-rlib` as well.
Store LLVM bitcode in object files, not compressed
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
In the code, test, and docs, because it makes it much easier to find
things.
Other than adding the comments about alphabetical order, this commit
only moves things around.
With the exception of `-C no-redzone`, because that could take a value
before this PR.
This partially undoes one of the earlier commits in this PR, which added
the ability to take a value to all boolean options that lacked it.
The help output for these options looks like this:
```
-C no-vectorize-slp=val -- disable LLVM's SLP vectorization pass
```
The "=val" part is a lie, but hopefully this will be fixed in the future.
This commit:
- Adds "following values" indicators for all the options that are
missing them.
- Tweaks some wording and punctuation for consistency.
- Rewords some things for clarity.
- Removes the `no-integrated-as` entry, because that option was removed
in #70345.
rustc_session: forbid lints override regardless of position
Addresses the regression reported in #70819 for command line arguments, but does not address the source code flag regression.
Add hash of source files in debug info
LLVM supports placing the hash of source files inside the debug info.
This information can be used by a debugger to verify that the source code matches
the executable.
This change adds support for both hash algorithms supported by LLVM, MD5 and SHA1, controlled by a target option.
* DWARF only supports MD5
* LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11).
* CodeView (.PDB) supports MD5, SHA1, and SHA256.
Fixes#68980.
Tracking issue: #70401
rustc dev guide PR with further details: https://github.com/rust-lang/rustc-dev-guide/pull/623
Make the rustc respect the `-C codegen-units` flag in incremental mode.
This PR implements (the as of yet unapproved) major change proposal at https://github.com/rust-lang/compiler-team/issues/245. See the description there for background and rationale.
The changes are pretty straightforward and should be easy to rebase if the proposal gets accepted at some point.
r? @nikomatsakis cc @pnkfelix
They used to be covered by `optin_builtin_traits` but negative impls
are now applicable to all traits, not just auto traits.
This also adds docs in the unstable book for the current state of auto traits.
Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book
A simple fix in docs - the sequence of words in basic example of negative trait implementation was reversed.
Small fixes in rustdoc book
I read the `rustdoc` book today and noticed some small typos/problems. Mainly:
- `# fn foo() {}` was displayed when not needed because fenced block code type was `text` instead of `rust`;
- two path separators were missing and some Windows-style separators were not consistent with the rest of them (mainly Linux-style).
Here are my proposed fixes. It is my first PR for the rust project. Don't hesitate to tell me if I am doing it wrong or if you need anything else.
Have a nice day!
