| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
|
|
|
|
We have a few ui tests to ensure we emit an error if we encounter too
big arrays. Before this fix, compiling the tests with `-Cdebuginfo=2`
would not include the spans of the instantiation sites, because the
error is then emitted from a different code path that does not include
the span.
Propagate the span to the error also in the debuginfo case, so the tests
passes regardless of debuginfo level.
|
|
We have a ui test to ensure we emit an error if we encounter too big
enums. Before this fix, compiling the test with `-Cdebuginfo=2` would
not include the span of the instantiation site, because the error is
then emitted from a different code path that does not include the span.
Propagate the span to the error also in the debuginfo case, so the test
passes regardless of debuginfo level.
|
|
This avoids the need for `#![allow(non_upper_case_globals)]`.
|
|
fix(debuginfo): handle false positives in overflow check
Fixes rust-lang/rust#144636.
Duplicate wrappers and normal recursive types can lead to false positives.
```rust
struct Recursive {
a: Box<Box<Recursive>>,
}
```
The ADT stack can be:
- `Box<Recursive>`
- `Recursive`
- `Box<Box<Recursive>>` (`Box` now detected as expanding)
We can filter them out by tracing the generic arg back through the stack, as true expanding recursive types must have their expanding arg used as generic arg throughout.
r? ````@wesleywiser````
|
|
|
|
|
|
This reverts commit 868bdde25b030e0b71a29a5dbc04a891036e702e.
|
|
This reverts commit b4d923cea0509933b1fb859930cb20784251f9be.
|
|
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
|
|
Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to "llvm.used". The volatile
load in the main shim is retained because "llvm.used", which translates
to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker;
emitting the volatile load ensures compatibility with older linkers, at
least when libstd is used.
Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that `omit_gdb_pretty_printer_section` keeps
working with dylib dependencies.
|
|
Disabling loading of pretty printers in the debugger itself is more
reliable. Before this commit the .gdb_debug_scripts section couldn't be
included in dylibs or rlibs as otherwise there is no way to disable the
section anymore without recompiling the entire standard library.
|
|
|
|
r=wesleywiser
fix(debuginfo): disable overflow check for recursive non-enum types
Commit b10edb4 introduce an overflow check when generating debuginfo for expanding recursive types. While this check works correctly for enums, it can incorrectly prune valid debug information for structures.
For example see rust-lang/rust#143241 (https://github.com/rust-lang/rust/issues/143241#issuecomment-3073721477). Furthermore, for structures such check does not make sense, since structures with recursively expanding types simply will not compile (there is a `hir_analysis_recursive_generic_parameter` for that).
closes rust-lang/rust#143241
|
|
|
|
recursive non-enum types
|
|
Make more of codegen_llvm safe
Best reviewed commit-by-commit.
|
|
|
|
|
|
|
|
infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
default data address space
|
|
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
|
|
It is only used within cg_llvm.
|
|
|
|
async_drop_in_place::{closure}, scoped async drop added.
|
|
avoid overflow when generating debuginfo for expanding recursive types
Fixes #135093
Fixes #121538
Fixes #107362
Fixes #100618
Fixes #115994
The overflow happens because expanding recursive types keep creating new nested types when recurring into sub fields.
I fixed that by returning an empty stub node when expanding recursion is detected.
|
|
This reverts commit 6adc2c1fd6ecde7bf83c8b8fbc71f402ced87054.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
compiler: Stop reexporting stuff in cg_llvm::abi
The reexports confuse tooling like rustdoc into thinking cg_llvm is the source of key types that originate in rustc_target.
|
|
The reexports confuse tooling like rustdoc into thinking cg_llvm is
the source of key types that originate in rustc_target.
|
|
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
|
|
debuginfo: Set bitwidth appropriately in enum variant tags
Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data.
LLVM added support for 128-bit enumerators in llvm/llvm-project#125578
That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing.
As a result, we went from emitting tags that looked like:
DW_AT_discr_value (0xfe)
(because `dwarf::BestForm` selected `data1`)
to emitting tags that looked like:
DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 )
This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which:
1. Is probably closer to our intentions in terms of describing the data.
2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools.
3. Will result in smaller debug information.
|
|
Previously, we unconditionally set the bitwidth to 128-bits, the largest
an discrimnator would possibly be. Then, LLVM would cut down the constant by
chopping off leading zeroes before emitting the DWARF. LLVM only
supported 64-bit descriminators, so this would also have occasionally
resulted in truncated data (or an assert) if more than 64-bits were
used.
LLVM added support for 128-bit enumerators in llvm/llvm-project#125578
That patchset also trusts the constant to describe how wide the variant tag is.
As a result, we went from emitting tags that looked like:
DW_AT_discr_value (0xfe)
(`form1`)
to emitting tags that looked like:
DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 )
This makes the `DW_AT_discr_value` encode at the bitwidth of the tag,
which:
1. Is probably closer to our intentions in terms of describing the data.
2. Doesn't invoke the 128-bit support which may not be supported by all
debuggers / downstream tools.
3. Will result in smaller debug information.
|
|
|
|
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
|
|
r=jieyouxu
Pick the max DWARF version when LTO'ing modules with different versions
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- From observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning.
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors.
- Debuggers need to be able to handle a variety of versions within the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions.
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
adds a test to ensure no warning is printed.
Fixes #130041 which fails due to these warnings being printed
cc #103057
|
|
|
