distinguish "no data" from "heterogeneous" in ABI
Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA.
cc #56877
r? @arielb1
cc @eddyb
Miri and miri-related code contains repetitions of `(n << amt) >> amt`
I reduced some code repetitions contains `(n << amt) >> amt`.
This pull request is related to #49937.
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes#46702Closes#54943Closes#57531Closes#57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
r? @nikomatsakis
bootstrap: Don't rely on any default settings regarding incr. comp. in Cargo
https://github.com/rust-lang/cargo/pull/6564 (temporarily) makes incremental compilation the default for release builds. We don't want this default to apply to building the compiler itself, that is, `bootstrap`'s `incremental` flag should always be respected. Otherwise we'll get incrementally build releases, which we really don't want `:)`.
r? @Mark-Simulacrum
Anybody else from @rust-lang/release should feel free to r+ this too if they get around to it earlier.
This commit extends existing suggestions to move lifetimes before types
in generic arguments to also suggest moving types behind associated type
bindings.
submodules: update clippy from 280069dd to f1753522
Changes:
````
Rustup
allow assertions_on_constants for collapsible_if and missing_test_files
Improving comments.
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Fixed potential mistakes with nesting. Added tests.
Fix automatic suggestion on `use_self`.
run ./util/dev update_lints
add assert(true/false, some message) tests
change assert_checks to assertions_on_constants
run ./util/dev update_lints
Add unreachable!() as option
Add assert(true) and assert(false) lints
````
Fixes clippy toolstate
r? @oli-obk
Rollup of 5 pull requests
Successful merges:
- #56217 (Add grammar in docs for {f32,f64}::from_str, mention known bug.)
- #57294 (When using value after move, point at span of local)
- #57652 (Update/remove some old readmes)
- #57802 (Print visible name for types as well as modules.)
- #57865 (Don't ICE when logging unusual types)
Failed merges:
r? @ghost
Don't ICE when logging unusual types
MonoItemExt#to_string is used for both debug logging and LLVM symbol
name generation. When debugging, we want to print out any type we
encounter, even if it's something weird like GeneratorWitness. However,
during codegen, we still want to error if we encounter an unexpected
type when generating a name.
To resolve this issue, this commit introduces a new 'debug' parameter to
the relevant methods. When set to 'true', it allows any type to be
printed - when set to 'false', it 'bug!'s when encountering an
unexpected type.
This prevents an ICE when enabling debug logging (via RUST_LOG) while
running rustc on generator-related code.
Print visible name for types as well as modules.
Fixes#56943 and fixes#57713.
This commit extends previous work in #55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
r? @estebank
When using value after move, point at span of local
When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.
```
error[E0382]: use of moved value: `x`
--> $DIR/issue-34721.rs:27:9
|
LL | pub fn baz<T: Foo>(x: T) -> T {
| - - move occurs because `x` has type `T`, which does not implement the `Copy` trait
| |
| consider adding a `Copy` constraint to this type argument
LL | if 0 == 1 {
LL | bar::bar(x.zero())
| - value moved here
LL | } else {
LL | x.zero()
| - value moved here
LL | };
LL | x.zero()
| ^ value used here after move
```
Fix#34721.
Changes:
````
Rustup
allow assertions_on_constants for collapsible_if and missing_test_files
Improving comments.
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Fixed potential mistakes with nesting. Added tests.
Fix automatic suggestion on `use_self`.
run ./util/dev update_lints
add assert(true/false, some message) tests
change assert_checks to assertions_on_constants
run ./util/dev update_lints
Add unreachable!() as option
Add assert(true) and assert(false) lints
````
Stabilize no_panic_pow
This would close#48320.
I'm not sure if I've done this right, I've just changed attribute name to stable and set `since` to two minor versions above current stable since that seemed like what others were doing.
Add suggestion for incorrect field syntax.
Fixes#57684.
This commit adds a suggestion when a `=` character is used when
specifying the value of a field in a struct constructor incorrectly
instead of a `:` character.
r? @estebank
rustdoc: fix ICE from loading proc-macro stubs
Fixes https://github.com/rust-lang/rust/issues/55399
When trying to resolve a macro, rustdoc first tries to load it from the resolver to see whether it's a Macros 2.0 macro, so it can return that Def before looking for any other kind of macro. However, this becomes a problem when you try to load proc-macros: since you can't use a proc-macro inside its own crate, this lookup also fails when attempting to link to it.
However, we have a hint that this lookup will fail: Macros which are actually `ProcMacroStub`s will fail the lookup, so we can use that information to skip loading the macro. Rustdoc will then happily check `resolve.all_macros`, which will return a usable Def that we can link to.
Get rid of the fake stack frame for reading from constants
r? @RalfJung
fixes the ice in https://github.com/rust-lang/rust/issues/53708 but still keeps around the wrong "non-exhaustive match" error
cc @varkor
Fix Instant/Duration math precision & associativity on Windows
**tl;dr** Addition and subtraction on Duration/Instant are not associative on windows because we use the perfcounter frequency in every calculation instead of just when we measure time.
This is my first contrib (PR or Issue) to Rust, so please lmk if I've done this wrong. I followed CONTRIBUTING to the extent I could given my system doesn't seem to be able to build the compiler with changes in the source tree. I also asked about this issue in #rust-beginners a week or so ago, before digging through libstd -- I'm unsure if there's a good way to follow up on that, but I'd be happy to update the docs on the timing structs if this fixes the problem.
## Issue
The `Duration` type keeps seconds in the upper-64 and nanoseconds in the lower-32 bits. In theory doing math on these ought to be basically the same as doing math on any other 64 or 32 bit integral number.
On windows (and I think macos too), however, our math gets messy because the Instant type stores the current point in time in units of HPET Performance Counter counts, not nanoseconds, and does unit conversions on every math operation, rather than just when we measure the time from the system clock.
I tried this code:
```
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On UNIX machines (linux and macos) it behaves as you'd expect -- [no crash](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cf2206c0b7e07d8ecc7767a512364094).
On Windows hosts, however, it blows up because of a precision problem in the Instant +/- Duration math:
```
C:\Users\aberg\work\timetest (master -> origin)
λ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running `target\debug\timetest.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `4.999914ms`,
right: `5ms`', src\main.rs:6:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: process didn't exit successfully: `target\debug\timetest.exe` (exit code: 101)
C:\Users\aberg\work\timetest (master -> origin)
λ cat src\main.rs
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On windows I think this is a consequence of doing the HPET-PerfCounter-Unit conversion on each math operation. I suspect the reason it works on macs is that (from what I could find online) most apple machines report timing in nanoseconds anyway. For anyone interested, the equivalent functions on macos, with a little work to fish out the numerator/denominator from a timebase struct:
* `QueryPerformanceCounter()` -> `mach_absolute_time()`
* `QueryPerformanceFrequency()` -> `mach_timebase_info()`
If this PR ends up working as I expect it to when CI runs the tests, I can make the same changes to the macos implementation.
## Potential Fix
We ought to be able to sort this out by storing nanoseconds, rather than PerfCounter units, that way intermediate math is done in the most precise units we support and we're only doing unit conversions when we actually measure the system clock (and it might even translate to a small perf gain for people doing tons of Instant/Duration math).
I believe this will address the underlying cause of #56034, and make the guessed epsilon constant from #56059 unnecessary. If it's of interest, I can write up how these timing types work on the tier 1 platforms to address #32626 as well, since I'm already in here figuring it out.
## This Patch
To that end, I've got this patch, which I think should fix it on windows, but I'm having trouble testing it -- any time I change anything in libstd I start getting this error, which no amount of clean building seems to resolve:
```
C:\Users\aberg\work\rust (master -> origin)
λ python x.py test --stage 0 --no-doc src/libstd
Updating only changed submodules
Submodules updated in 0.27 seconds
Finished dev [unoptimized] target(s) in 2.41s
Building stage0 std artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Finished release [optimized] target(s) in 6.78s
Copying stage0 std from stage0 (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc / x86_64-pc-windows-msvc)
Building stage0 test artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Compiling test v0.0.0 (C:\Users\aberg\work\rust\src\libtest)
error[E0460]: found possibly newer version of crate `std` which `getopts` depends on
--> src\libtest\lib.rs:36:1
|
36 | extern crate getopts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-d7a80ca2ae113c97.rlib
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\std-d7a80ca2ae113c97.dll
crate `getopts`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-test\x86_64-pc-windows-msvc\release\deps\libgetopts-ae40a96de5f5d144.rlib
error: aborting due to previous error
For more information about this error, try `rustc --explain E0460`.
error: Could not compile `test`.
To learn more, run the command again with --verbose.
command did not execute successfully: "C:\\Users\\aberg\\work\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "build" "--target" "x86_64-pc-windows-msvc" "-j" "12" "--release" "--manifest-path" "C:\\Users\\aberg\\work\\rust\\src/libtest/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: C:\Users\aberg\work\rust\build\bootstrap\debug\bootstrap test --stage 0 --no-doc src/libstd
Build completed unsuccessfully in 0:00:20
```
---
Since you wrote the linked PRs and might remember looking at related problems:
r? @alexcrichton
Remove quote_*! macros
This deletes a considerable amount of test cases, some of which we may want to keep. I'm not entirely certain what the primary intent of many of them was; if we should keep them I can attempt to edit each case to continue compiling without the quote_*! macros involved.
Fixes#46849.
Fixes#12265.
Fixes#12266.
Fixes#26994.
r? @Manishearth
Add intrinsic to create an integer bitmask from a vector mask
This PR adds a new simd intrinsic: `simd_bitmask(vector) -> unsigned integer` that creates an integer bitmask from a vector mask by extracting one bit of each vector lane.
This is required to implement: https://github.com/rust-lang-nursery/packed_simd/issues/166 .
EDIT: the reason we need an intrinsics for this is that we have to truncate the vector lanes to an `<i1 x N>` vector, and then bitcast that to an `iN` integer (while making sure that we only materialize `i8`, ... , `i64` - that is, no `i1`, `i2`, `i4`, types), and we can't do any of that in a Rust library.
r? @rkruppe
Rollup of 11 pull requests
Successful merges:
- #57179 (Update std/lib.rs docs to reflect Rust 2018 usage)
- #57730 (Merge visitors in AST validation)
- #57779 (Recover from parse errors in literal struct fields and incorrect float literals)
- #57793 (Explain type mismatch cause pointing to return type when it is `impl Trait`)
- #57795 (Use structured suggestion in stead of notes)
- #57817 (Add error for trailing angle brackets.)
- #57834 (Stabilize Any::get_type_id and rename to type_id)
- #57836 (Fix some cross crate existential type ICEs)
- #57840 (Fix issue 57762)
- #57844 (use port 80 for retrieving GPG key)
- #57858 (Ignore line ending on older git versions)
Failed merges:
r? @ghost
