Fix LLVM IR generated for C-variadic arguments
It is possible to create malformed LLVM IR given variadic arguments that
are aggregate types. This occurs due to improper tracking of the current
argument in the functions list of arguments.
Fixes: #58881
It is possible to create malformed LLVM IR given variadic arguments that
are aggregate types. This occurs due to improper tracking of the current
argument in the functions list of arguments.
skip dyn keyword lint under macros
This PR is following my own intuition that `rustfix` should never inject bugs into working code (even if that comes at the expense of it failing to fix things that will become bugs).
Fix#56327
Fix invalid DWARF for enums when using ThinLTO
We were setting the same identifier for both the DW_TAG_structure_type
and the DW_TAG_variant_part. This becomes a problem when using ThinLTO
becauses it uses the identifier as a key for a map of types that is used
to delete duplicates based on the ODR, so one of them is deleted as a
duplicate, resulting in invalid DWARF.
The DW_TAG_variant_part isn't a standalone type, so it doesn't need
an identifier. Fix by omitting its identifier.
ODR uniquing is [enabled here](f21dee2c61/src/rustllvm/PassWrapper.cpp (L1101)).
Whitelist some rustc attrs
These rustc attrs are used within libcore, and were causing failures when one mixed incremental compilation with bootstrapping (due to a default of `-D warnings` when bootstrapping).
Fix#59523Fix#59524
Cc #58633
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
Review feedback asked for the test to be generalized to include macros
2.0; that generalization is dyn-2015-idents-in-decl-macros-unlinted.rs
As a drive-by, I also decided to revise the test to make it clear
*why* we cannot generally lint these cases. (I already had similar
demonstrations in dyn-2015-edition-keyword-ident-lint.rs, but it does
not hurt to try to emphasize matters.)
I also added some commentary on the cases where we could choose to
make the lint smarter, namely the situations where a macro is
*definitely* using `dyn` as an identifier (because it is using it as a
path component).
Back-story: After reflection this morning, I realized that the
previous form of this test would allow the macro invocation to treat
the `dyn` input as a raw-identifier rather than a keyword, and since
the input was discarded by that version of the macro, the test would
pass despite the detail that the input `dyn` should not have been
parsed as a raw-identifier.
This revision fixes that oversight, by actually *using* the macro
input to construct a `Box<dyn Trait>` type.
