- adds handling of zero-sized types for volatile_store.
- adds type size checks and warnigns for other volatile intrinsics.
- adds a test to check warnings emitting.
Cause of the issue
While preparing for trans_intrinsic_call() invoke arguments are
processed with trans_argument() method which excludes zero-sized types
from argument list (to be more correct - all arguments for which
ArgKind is Ignore are filtered out). As result volatile_store() intrinsic
gets one argument instead of expected address and value.
How it is fixed
Modification of the trans_argument() method may cause side effects,
therefore change was implemented in volatile_store() intrinsic building
code itself. Now it checks function signature and if it was specialised
with zero-sized type, then emits C_nil() instead of accessing
non-existing second argument.
Additionally warnings are added for all volatile operations which are
specialised with zero-sized arguments. In fact, those operations are omitted
in LLVM backend if no memory affected at all, e.g. number of elements
is zero or type is zero-sized. This was not explicitly documented before
and could lead to potential issues if developer expects volatile behaviour,
but type has degraded to zero-sized.
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
r? @nagisa
Some assorted region hashing fixes.
This PR contains three changes.
1. It changes what we implement `HashStable` for. Previously, the trait was implemented for things in the local `TyCtxt`. That was OK, since we only invoked hashing with a `TyCtxt<'_, 'tcx, 'tcx>` where there is no difference. With query result hashing this becomes a problem though. So we now implement `HashStable` for things in `'gcx`.
2. The PR makes the regular `HashStable` implementation *not* anonymize late-bound regions anymore. It's a waste of computing resources and it's not clear that it would always be correct to do so.
3. The PR adds an option for stable hashing to treat all regions as erased and uses this new option when computing the `TypeId`. This should help with https://github.com/rust-lang/rust/issues/41875.
I did not add a test case for (3) since that's not possible yet. But it looks like @zackmdavis has something in the pipeline there `:)`.
r? @eddyb
Hint correct extern constant syntax
Error message for `extern "C" { const …}` is terse, and the right syntax is hard to guess given unfortunate difference between meaning of `static` in C and Rust.
I've added a hint for the right syntax.
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
rustc: Rearchitect lints to be emitted more eagerly
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
Closes https://github.com/rust-lang/rust/issues/42511
Fixed mutable vars being marked used when they weren't
#### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue.
Fixes#43526, Fixes#30280, Fixes#25049
### Issue
Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings
```
fn do_thing<T>(mut arg : &mut T) {
... // don't touch arg - just deref it to access the T
}
```
### Fix
Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables.
#### Why not on things other than local variables?
* Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted.
* If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
Avoid calling the column!() macro in panic
Closes#43057
This "fix" adds a new macro called `__rust_unstable_column` and to use it instead of the `column` macro inside panic. The new macro can be shadowed as well as `column` can, but its very likely that there is no code that does this in practice.
There is no real way to make "unstable" macros that are usable by stable macros, so we do the next best thing and prefix the macro with `__rust_unstable` to make sure people recognize it is unstable.
r? @alexcrichton
Point at return type always when type mismatch against it
Before this, the diagnostic errors would only point at the return type
when changing it would be a possible solution to a type error. Add a
label to the return type without a suggestion to change in order to make
the source of the expected type obvious.
Follow up to #42850, fixes#25133, fixes#41897.
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
#[must_use] for functions
This implements [RFC 1940](https://github.com/rust-lang/rfcs/pull/1940).
The RFC and discussion thereof seem to suggest that tagging `PartialEq::eq` and friends as `#[must_use]` would automatically lint for unused comparisons, but it doesn't work out that way (at least the way I've implemented it): unused `.eq` method calls get linted, but not `==` expressions. (The lint operates on the HIR, which sees binary operations as their own thing, even if they ultimately just call `.eq` _&c._.)
What do _you_ think??
Resolves#43302.
Optimize initialization of arrays using repeat expressions
This PR was inspired by [this thread](https://www.reddit.com/r/rust/comments/6o8ok9/understanding_rust_performances_a_newbie_question/) on Reddit.
It tries to bring array initialization in the same ballpark as `Vec::from_elem()` for unoptimized builds.
For optimized builds this should relieve LLVM of having to figure out the construct we generate is in fact a `memset()`.
To that end this emits `llvm.memset()` when:
* the array is of integer type and all elements are zero (`Vec::from_elem()` also explicitly optimizes for this case)
* the array elements are byte sized
If the array is zero-sized initialization is omitted entirely.
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.
As part of the CTFE initiative, we're forced to find a solution for floating-point operations.
By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads).
If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms.
That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR).
Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics.
The options considered by @rust-lang/compiler were:
1. Ban floating-point operations in generic const-evaluation contexts
2. Emulate floating-point operations in an uniformly deterministic fashion
The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole.
Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE.
I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on.
But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR.
This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it.
I've also ported all the testcases over, *before* any functionality, to catch any mistakes.
Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations.
Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around.
r? @nikomatsakis
f? @nagisa @est31
<hr/>
Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
Unskip some tests on AArch64
I've been running the test suite remotely on an Acer Chromebook R13 and natively on an ARM Juno developer board, both AArch64 devices. Most of the tests that are skipped on AArch64 are due to testing stdcall/fastcall/x86-specific code or the debugger, but I've found a few tests that could be enabled there.
These have been skipped previously due to failing on the `aarch64-linux-android` and `mac-android` buildbots, more than 2 years ago (#23471, #23695). It seems we don't test those platforms any more, but as they do work on AArch64 Linux, I'd like to propose re-enabling them. All of them pass on my devices.
Add a more precise error message for issue #35976
When trying to perform static dispatch on something which derefs to a trait object, and the target trait is not in scope, we had confusing error messages if the target method had a `Self: Sized` bound. We add a more precise error message in this case: "consider using trait ...".
Fixes#35976.
r? @nikomatsakis
field does not exist error: note fields if Levenshtein suggestion fails
When trying to access or initialize a nonexistent field, if we can't infer what
field was meant (by virtue of the purported field in the source being a small
Levenshtein distance away from an actual field, suggestive of a typo), issue a
note listing all the available fields. To reduce terminal clutter, we don't
issue the note when we have a `find_best_match_for_name` Levenshtein
suggestion: the suggestion is probably right.
The third argument of the call to `find_best_match_for_name` is changed to
`None`, accepting the default maximum Levenshtein distance of one-third of the
identifier supplied for correction. The previous value of `Some(name.len())`
was overzealous, inappropriately very Levenshtein-distant suggestions when the
attempted field access could not plausibly be a mere typo. For example, if a
struct has fields `mule` and `phone`, but I type `.donkey`, I'd rather the
error have a note listing that the available fields are, in fact, `mule` and
`phone` (which is the behavior induced by this patch) rather than the error
asking "did you mean `phone`?" (which is the behavior on master). The "only
find fits with at least one matching letter" comment was accurate when it was
first introduced in 09d992471 (January 2015), but is a vicious lie in its
present context before a call to `find_best_match_for_name` and must be
destroyed (replacing every letter is within a Levenshtein distance of name.len()).
The present author claims that this suffices to resolve#42599.
Add MIR Validate statement
This adds statements to MIR that express when types are to be validated (following [Types as Contracts](https://internals.rust-lang.org/t/types-as-contracts/5562)). Obviously nothing is stabilized, and in fact a `-Z` flag has to be passed for behavior to even change at all.
This is meant to make experimentation with Types as Contracts in miri possible. The design is definitely not final.
Cc @nikomatsakis @aturon
