| Age | Commit message (Collapse) | Author | Lines |
|---|
|
### Overview
This commit begins the implementation work for RFC 2945. For more
information, see the rendered RFC [1] and tracking issue [2].
A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI
boundaries is acceptable. The cases where each of these variants'
`unwind` member is true correspond with the `C-unwind`,
`system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
introduced in RFC 2945 [3].
### Feature Gate and Unstable Book
This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`,
which ensure that this feature gate works correctly for each of the
new ABIs.
A new language features entry in the unstable book is added as well.
### Further Work To Be Done
This commit does not proceed to implement the new unwinding ABIs,
and is intentionally scoped specifically to *defining* the ABIs and
their feature flag.
### One Note on Test Churn
This will lead to some test churn, in re-blessing hash tests, as the
deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
because we can no longer guarantee the ordering of the `Abi`
variants.
While this is a downside, this decision was made bearing in mind
that RFC 2945 states the following, in the "Other `unwind` Strings"
section [3]:
> More unwind variants of existing ABI strings may be introduced,
> with the same semantics, without an additional RFC.
Adding a new variant for each of these cases, rather than specifying
a payload for a given ABI, would quickly become untenable, and make
working with the `Abi` enum prone to mistakes.
This approach encodes the unwinding information *into* a given ABI,
to account for the future possibility of other `-unwind` ABI
strings.
### Ignore Directives
`ignore-*` directives are used in two of our `*-unwind` ABI test
cases.
Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
ignore architectures that do not support `stdcall` and
`thiscall`, respectively.
These directives are cribbed from
`src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
`src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
This would otherwise fail on some targets, see:
https://github.com/rust-lang-ci/rust/commit/fcf697f90206e9c87b39d494f94ab35d976bfc60
### Footnotes
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
|
|
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.
See the page on the unstable book for details.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
|
|
|
|
diagnostics: shorten paths of unique symbols
This is a step towards implementing a fix for #50310, and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed, and I should just come up with code.
The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions, it's rather simple logic, and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors.
-----
If a symbol name can only be imported from one place, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path to the last component.
This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable from anywhere.
|
|
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
|
|
If a comma in a format call is replaced with a similar token, then we
emit an error and continue parsing, instead of stopping at this point.
|
|
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
|
|
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
|
|
r=nikomatsakis"
This reverts commit 372cb9b69c76a042d0b9d4b48ff6084f64c84a2c, reversing
changes made to 5c61a8dc34c3e2fc6d7f02cb288c350f0233f944.
|
|
|
|
Explain move errors that occur due to method calls involving `self`
When calling a method that takes `self` (e.g. `vec.into_iter()`), the method receiver is moved out of. If the method receiver is used again, a move error will be emitted::
```rust
fn main() {
let a = vec![true];
a.into_iter();
a;
}
```
emits
```
error[E0382]: use of moved value: `a`
--> src/main.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| - value moved here
4 | a;
| ^ value used here after move
```
However, the error message doesn't make it clear that the move is caused by the call to `into_iter`.
This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method::
```
error[E0382]: use of moved value: `a`
--> vec.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| ------------- value moved due to this method call
4 | a;
| ^ value used here after move
|
note: this function takes `self`, which moves the receiver
--> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5
|
239 | fn into_iter(self) -> Self::IntoIter;
```
TODO:
- [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods
- [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`)
- [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.
|
|
|
|
|
|
|
|
|
|
Moving more build-pass tests to check-pass
One or two tests became build-pass without the FIXME because they really
needed build-pass (were failing without it).
Helps with #62277
---
<!-- Reviewable:start -->
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/71340)
<!-- Reviewable:end -->
|
|
|
|
One or two tests became build-pass without the FIXME because they really
needed build-pass (were failing without it).
Helps with #62277
|
|
|
|
Add long error explanation for E0703
Add long explanation for the E0703 error code
Part of #61137
r? @GuillaumeGomez
|
|
They used to be covered by `optin_builtin_traits` but negative impls
are now applicable to all traits, not just auto traits.
This also adds docs in the unstable book for the current state of auto traits.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change makes error and warning annotations mandatory in UI tests.
The only exception are tests that use error patterns to match compiler
output and don't have any annotations.
|
|
|
|
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest
version of the UEFI specification at the time of commit (UEFI spec 2.8,
URL below). The specification says that for x86_64, we should follow the
win64 ABI, while on all other supported platforms (ia32, itanium, arm,
arm64 and risc-v), we should follow the C ABI.
To simplify the implementation, we will simply follow the C ABI on all
platforms except x86_64, even those technically unsupported by the UEFI
specification.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
|
|
|
|
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is based on the feedback from estebank:
"""
I believe that test can be removed outright. It'd be impossible for a
new change to go through that breaks this kind of output without it
being picked up by multiple other `stderr` tests. This is an artifact
of the transition period to the "new" output style.
"""
see: https://github.com/rust-lang/rust/issues/52663#issuecomment-422155551
|
|
|
|
Give a special message when the later use is from a call. Use the span
of the callee instead of the whole expression. For conflicting borrow
messages say that the later use is of the first borrow.
|
|
Fixes #54133.
|
