I spent a while debugging a strage linker error about an outdated `glibc` version, only to discover that it was caused by a stale `obj` directory. It wasn't obviously to be that using the same obj dir with multiple Docker images (for the same target triple) could be a problem.
This commit adds a note to the README, which should hopefully be helpful to anyone else who runs into this issue.
Rename `bool::then_*` to `bool::to_option_*` and use where appropriate
Name change following https://github.com/rust-lang/rfcs/pull/2757. Also try it out throughout the compiler in places I think makes the code more readable.
We now only propagate a scalar pair if the Rvalue is a tuple with two
scalars. This for example avoids propagating a (u8, u8) value when
Rvalue has type `((), u8, u8)` (see the regression test). While this is
a correct thing to do, implementation is tricky and will be done later.
Fixes#66971Fixes#66339Fixes#67019
Migrate to LLVM{Get,Set}ValueName2
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Closes#64223.
r? @rkruppe
SGX: Fix target linker used by bootstrap
Bootstrap, for some reason, overrides the target linker. This is not correct for x86_64-fortanix-unknown-sgx. Add such targets to the list of exceptions.
r? @alexcrichton
Remove potential cfgs duplicates
Fixes https://github.com/rust-lang/rust/issues/66921.
Before going any further (the issue seems to be linked to metadata as far as I can tell). Do you think this is the good place to do it or should it be done before?
r? @eddyb
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
The polonius output has one more error which should be displayed
in the regular case, but error reporting in the regular case stopped
at the first error.
Admittedly it would be nice to combine suggestions for the same source
lifetime so that `'a: 'b` and `'a: 'c` are not bothsuggested, but instead
a single `'a: 'b + 'c` is.
- adapt to the new polonius `FactTypes` API
- reorganize the type aliases referring to polonius to avoid referencing the inner atom or fact types multiple times: only one input and output types should be enough for everyone. They could equally be in `borrow_check` as `nll` though.
