rustc: Don't enable NEON by default on armv7 Linux
One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target,
Linux distributions, do not enable NEON extensions by default. This PR disables
that feature by defualt but enables the `d16` feature which enables VFP3D16 that
distributions do enable.
Closes#35590
Remove the old AST-based backend from rustc_trans.
Starting with Rust 1.13, `--disable-orbit` , `-Z orbit=off` and `#[rustc_no_mir]` have been removed.
Only the new MIR backend is left in the compiler, and only early const_eval uses ASTs from other crates.
Filling drop (previously "zeroing drop"), `#[unsafe_no_drop_flag]` and associated unstable APIs are gone.
Implementing `Drop` doesn't add a flag anymore to the type, all of the dynamic drop is function local.
This is a [breaking-change], please use `Option::None` and/or `mem::forget` if you are unsure about your ability to prevent/control the drop of a value. In the future, `union` will be usable in some such cases.
**NOTE**: DO NOT MERGE before we get the new beta as the stage0, there's some cruft to remove.
All of this will massively simplify any efforts to implement (and as such it blocks) features such as `union`s, safe use of `#[packed]` or new type layout optimizations, not to mention many other experiments.
more evocative examples for `Sub` and `SubAssign`
These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in.
Part of #29365.
r? @steveklabnik
The memrchr fallback did not compute the offset correctly. It was
intentioned to land on usize-aligned addresses but did not.
This was suspected to resulted in a crash on ARMv7 platform!
This bug affected non-linux platforms.
I think like this, if we have a slice with pointer `ptr` and length
`len`, we want to find the last usize-aligned offset in the slice.
The correct computation should be:
For example if ptr = 1 and len = 6, and size_of::<usize>() is 4:
[ x x x x x x ]
1 2 3 4 5 6
^-- last aligned address at offset 3 from the start.
The last aligned address is ptr + len - (ptr + len) % usize_size.
Compute offset from the start as:
offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3.
I believe the function's return value was always correct previously, if
the platform supported unaligned addresses.
Make version check in gdb_rust_pretty_printing.py more compatible.
Some versions of Python don't support the `major` field on the object returned by `sys.version_info`.
Fixes#35724
r? @brson
r? @steveklabnik
add examples that lift `<<` and `>>` to a trivial struct
replace `Scalar` structs with struct tuples
add `fn main` wrappers to enable Rust Playground "Run" button
compute and cache HIR hashes at beginning
This avoids the compile-time overhead of computing them twice. It also fixes
an issue where the hash computed after typeck is differen than the hash before,
because typeck mutates the def-map in place.
Fixes#35549.
Fixes#35593.
Some performance measurements suggest this `HashesMap` is very small in memory (unobservable via `-Z time-passes`) and very cheap to construct. I do see some (very minor) performance wins in the incremental case after the first run -- the first run costs more because loading the dep-graph didn't have any hashing to do in that case. Example timings from two runs of `libsyntex-syntax` -- the (1) indicates first run, (2) indicates second run, and (*) indicates both together:
| Phase | Master | Branch |
| ---- | ---- | ---- |
| compute_hashes_map (1) | N/A | 0.343 |
| load_dep_graph (1) | 0 | 0 |
| serialize dep graph (1) | 4.190 | 3.920 |
| total (1) | 4.190 | 4.260 |
| compute_hashes_map (2) | N/A | 0.344 |
| load_dep_graph (2) | 0.592 | 0.252 |
| serialize dep graph (2) | 4.119 | 3.779 |
| total (2) | 4.71 | 4.375 |
| total (*) | 8.9 | 8.635 |
r? @michaelwoerister
I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
add module-level documentation for `Fn*` traits
Describe how `Fn*` traits, closure types, and ownership semantics are
linked, and provide examples of higher-level functions that take `Fn*`s.
more examples for `Fn*` traits
create correct (though not yet elegant) examples for `FnMut` and `FnOnce`
add trait links to module-level documentation
third time's a charm!
argument -> capture for trait documentation
This wording will need to be supported with better examples for
capturing eventually.
correct `FnOnce` example
I also fixed some of the trait wording here to make the concept of
capturing clearer; though that still needs more work.
replace `x + x` with `x * 2` for `fn double`
