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.
This commit does the following.
- Changes the terminology for capacities used within HashMap's code.
"Internal capacity" is now consistently "raw capacity", and "usable
capacity" is now consistently just "capacity". This makes the code
easier to understand.
- Reworks capacity and raw capacity computations. Raw capacity
computations are now handled in a single place:
`DefaultResizePolicy::raw_capacity()`. This function correctly returns
zero when given zero, which means that the following cases now result
in a capacity of zero when they previously did not.
* `Hash{Map,Set}::with_capacity(0)`
* `Hash{Map,Set}::with_capacity_and_hasher(0)`
* `Hash{Map,Set}::shrink_to_fit()`, when used with a hash map/set whose
elements have all been removed
- Strengthens the language used in the comments describing the above
functions, to make it clearer when they will result in a map/set with
a capacity of zero. The new language is based on the language used for
the corresponding functions in `Vec`.
- Adds tests for the above zero-capacity cases.
- Removes `test_resize_policy` because it is no longer useful.
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)]`.
This applies the HIR changes from the previous commits to the AST, and
is thus a syntax-[breaking-change]
Renames `PatKind::Vec` to `PatKind::Slice`, since these are called slice
patterns, not vec patterns. Renames `TyKind::Vec`, which represents the
type `[T]`, to `TyKind::Slice`. Renames `TyKind::FixedLengthVec` to
`TyKind::Array`.
