When overflow checking on `<<` and `>>` was added for integers, the `<<` and `>>` operations broke for SIMD types (`u32x4`, `i16x8`, etc.). This PR implements checked shifts on SIMD types.
Fixes#24258.
This has a number of advantages compared to creating a copy in memory
and passing a pointer. The obvious one is that we don't have to put the
data into memory but can keep it in registers. Since we're currently
passing a pointer anyway (instead of using e.g. a known offset on the
stack, which is what the `byval` attribute would achieve), we only use a
single additional register for each fat pointer, but save at least two
pointers worth of stack in exchange (sometimes more because more than
one copy gets eliminated). On archs that pass arguments on the stack, we
save a pointer worth of stack even without considering the omitted
copies.
Additionally, LLVM can optimize the code a lot better, to a large degree
due to the fact that lots of copies are gone or can be optimized away.
Additionally, we can now emit attributes like nonnull on the data and/or
vtable pointers contained in the fat pointer, potentially allowing for
even more optimizations.
This results in LLVM passes being about 3-7% faster (depending on the
crate), and the resulting code is also a few percent smaller, for
example:
text data filename
5671479 3941461 before/librustc-d8ace771.so
5447663 3905745 after/librustc-d8ace771.so
1944425 2394024 before/libstd-d8ace771.so
1896769 2387610 after/libstd-d8ace771.so
I had to remove a call in the backtrace-debuginfo test, because LLVM can
now merge the tails of some blocks when optimizations are turned on,
which can't correctly preserve line info.
Fixes#22924
Cc #22891 (at least for fat pointers the code is good now)
When taking the address of an unsized field we generate a rvalue datum
for the field and then convert it to an lvalue datum. At that point,
cleanup is scheduled for the field, leading to multiple drop calls.
The problem is that we generate an rvalue datum for the field, since the
pointer does not own the data and there's already cleanup scheduled
elsewhere by the true owner. Instead, an lvalue datum must be created.
Thanks to @eddyb for identifying the underlying cause and suggesting the
correct fix.
Fixes#25549.
I think I didn't run tests properly - my second call to
select_all_obligations_or_error has made 3 tests fail. However, this is
just an error message change - integer fallback never worked with casts.
This should hopefully fix all cast-related ICEs once and for all.
I managed to make diagnostics hate me and give me spurious "decoder error"
- removing $build/tmp/extended-errors seems to fix it.
When taking the address of an unsized field we generate a rvalue datum
for the field and then convert it to an lvalue datum. At that point,
cleanup is scheduled for the field, leading to multiple drop calls.
The problem is that we generate an rvalue datum for the field, since the
pointer does not own the data and there's already cleanup scheduled
elsewhere by the true owner. Instead, an lvalue datum must be created.
Thanks to @eddyb for identifying the underlying cause and suggesting the
correct fix.
Fixes#25549Fixes#25515
* segfault due to not copying drop flag when coercing
* fat pointer casts
* segfault due to not checking drop flag properly
* debuginfo for DST smart pointers
* unreachable code in drop glue
The former stopped making sense when we started interning substs and made
TraitRef a 2-word copy type, and I'm moving the latter into an arena as
they live as long as the type context.
the plan is to treat all binary operators as if they were overloaded,
relying on the fact that we have impls for all the builtin scalar
operations (and no more). But then during writeback we clear the
overload if the types correspond to a builtin op.
This strategy allows us to avoid having to know the types of the
operands ahead of time. It also avoids us overspecializing as we did in
the past.
This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
After this patch code like `let ref a = *"abcdef"` doesn't cause ICE anymore.
Required for #23121
There are still places in rustc_trans where pointers are always assumed to be thin. In particular, #19064 is not resolved by this patch.
This includes a slight refactoring of the `cast_shift_rhs` and related
functions in `trans::base`, so that I can call them from much later in
the compiler's control flow (so that we can clearly dilineate where
automatic conversions of the RHS occur, versus where we check it).
The rhs-checking and fallback-masking is generalized to 8- and 16-bit
values, and the fallback-masking is turned on unconditionally.
Fix#10183.
Is this a [breaking-change]? I would argue it is not; it only adds a
strict definition to what was previously undefined behavior; however,
there might be code that was e.g. assuming that `1_i8 << 17` yields 0.
(This happens in certain contexts and at certain optimization levels.)
Safe fns are no longer subtypes of unsafe fns, but you can coerce from one to the other.
This is a [breaking-change] in that impl fns must now be declared `unsafe` if the trait is declared `unsafe`. In some rare cases, the subtyping change may also direct affect you, but no such cases were encountered in practice.
Fixes#23449.
r? @nrc
