add wrapper for discriminant_value, take 2
[This is #34785 reopened, since @bors apparently gave up on that thread.]
add wrapper for discriminant_value intrinsic
Implementation of [RFC 1696](https://github.com/rust-lang/rfcs/blob/master/text/1696-discriminant.md).
Wraps the `discriminant_value` intrinsic under the name `std::mem::discriminant`. In order to avoid prematurely leaking information about the implementation of enums, the return value is an opaque type, generic over the enum type, which implements Copy, Clone, PartialEq, Eq, Hash, and Debug (notably not PartialOrd). There is currently no way to get the value out excepting printing the debug representation.
The wrapper is safe and can be stabilized soon as per discussion in #24263.
cc @aturon
r? @nagisa
Resolve the callee type in check_call before autoderef
If the callee type is an associated type, then it needs to be normalized
before trying to deref it. This matches the behaviour of
`check_method_call` for autoderef behaviour in calls.
Fixes#36786
Clean up hasher discussion on HashMap
* We never want to make guarantees about protecting against attacks.
* "True randomness" is not the right terminology to be using in this
context.
* There is significantly more nuance to the performance of SipHash than
"somewhat slow".
r? @steveklabnik
Follow up to discussion on #35371
Change encode_utf{8,16}() to write to a buffer and panic if it's too small
cc #27784
Should the "A buffer that's too small" examples be removed and replaced by tests?
Move MIR towards a single kind of local
This PR modifies MIR to handle function arguments (`Arg`), user-defined variable bindings (`Var`), compiler-generated temporaries (`Tmp`), as well as the return value pointer equally. All of them are replaced with a single `Local` type, a few functions for iterating over different kinds of locals, and a way to get the kind of local we're dealing with (mainly used in the constant qualification/propagation passes).
~~I haven't managed to fix one remaining issue: A `StorageDead` not getting emitted for a variable (see the `TODO` in the test). If that's fixed, this is basically good to go.~~ Found the issue (an off-by-one error), fix incoming.
r? @eddyb for changes to constant qualification and propagation I'm not quite sure about
This does not actually add anything that wasn't there, but is merely an
optimization for the given cases, which would have incurred additional
heap allocation for adding empty strings, and improving the ergonomics
of `Cow` with strings.
rustbuild: Use current_dir instead of -C
Apparently some versions of git don't support the `-C` flag, so let's use the
guaranteed-to-work `current_dir` function.
If the callee type is an associated type, then it needs to be normalized
before trying to deref it. This matches the behaviour of
`check_method_call` for autoderef behaviour in calls.
Fixes#36786
add a panic-strategy field to the target specification
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
closes#36647
---
I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this?
Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate.
r? @alexcrichton
cc @phil-opp
Allow more non-inline modules in blocks
Currently, non-inline modules without a `#[path]` attribute are not allowed in blocks.
This PR allows non-inline modules that have an ancestor module with a `#[path]` attribute, provided there is not a nearer ancestor block.
For example,
```rust
fn main() {
#[path = "..."] mod foo {
mod bar; //< allowed by this PR
fn f() {
mod bar; //< still an error
}
}
}
```
Fixes#36772.
r? @nikomatsakis
Allow supplying an error destination via the compiler driver
Allows replacing stderr with a buffer from the client.
Also, some refactoring around run_compiler.
Remove CString drop test.
The test relies on the undefined behavior, and so may fail in some
circumstances. This can be worked around by stubbing a memory allocator
in the test, but it is a bit of work, and LLVM could still theoretically
eliminate the write of the zero byte in release mode (which is
intended).
So let's just remove the test and mark the function as inline. It
shouldn't be optimized away when inlined into the debug build of user's
code.
Supersedes #36607
r? @alexcrichton
Move ty_align and ty_size out of most C ABI code
s390x's C ABI ty_align and ty_size are not moved because the
implementation of ty_align varies in an atypical pattern: it calls
ty_size for the llvm::Vector type kind. ty_size then cannot be moved
since it indirectly calls ty_align through align.
Fixes#5116 (probably, not sure).
remove ExactSizeIterator from RangeInclusive<{u,i}{32,size}>
Fixes#36386.
This is a [breaking-change] for nightly users of `#![feature(inclusive_range_syntax)]` and/or `#![feature(inclusive_range)]`.
update mips64* data-layout
I tried to compile some (`#![no_core]`) code for the `mips64` targets on the latest nightly and got ICE's about mismatched data layouts. I updated the data layouts to match the listed llvm defaults.
cc @japaric
Funnily enough, this seems to be the exact reverse of what @japaric did in 2222d437a7 as part of #36024.
Remove requirement to use 10.7 (fixes macOS)
Fixes https://github.com/rust-lang/rust/issues/36650 by removing the requirement to use 10.7. @alexcrichton pointed out that the buildbots won't be affected, since they set the requirement with an environment variable.
This should now allow rustbuild to build Rust on macOS (nee OS X)
r? @alexcrichton
rustc: Tweak expansion order of custom derive
This commit alters the expansion order of custom macros-1.1 style `#[derive]`
modes. Instead of left-to-right the expansion now happens in three categories,
each of which is internally left-to-right:
* Old-style custom derive (`#[derive_Foo]`) is expanded
* New-style custom derive (macros 1.1) is expanded
* Built in derive modes are expanded
This gives built in derive modes maximal knowledge about the struct that's being
expanded and also avoids pesky issues like exposing `#[structural_match]` or
`#[rustc_copy_clone_marker]`.
cc #35900
