| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Detect async visibility wrong order, `async pub`
Partially address #76437.
|
|
async-pub check created a regression for default
|
|
|
|
Redirects `const? async? unsafe? pub` to `pub const? async? unsafe?`.
Fix #76437
|
|
|
|
|
|
### 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
|
|
Move rustdoc UI tests into a subdirectory
Helps with https://github.com/rust-lang/rust/issues/73494.
|
|
This also adds a little leeway to the test limit.
|
|
expand: Refactor module loading
This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399, but they can be landed independently.
See individual commits for more details.
Anyone should be able to review this equally well because all people actually familiar with this code left the project.
|
|
Move some tests to more suitable subdirs
## The results from classifui
(The full results can be found here: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427)
- [lint-expr-stmt-attrs-for-early-lints.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint-expr-stmt-attrs-for-early-lints.rs) <sup>unknown</sup>: lint (1.566), feature-gates (-0.632), numbers-arithmetic (-0.955)
- [try-block.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/try-block.rs) <sup>unknown</sup>: binding (1.385), try-block (-0.097), lint (-0.932)
- [backtrace-debuginfo.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/backtrace-debuginfo.rs) <sup>unknown</sup>: macros (1.365), cfg (-0.279), drop (-0.291)
- [issues/issue-3521.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-3521.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/3521)</sup>: consts (1.298), enum (-0.872), in-band-lifetimes (-0.978)
- [impl-bounds-checking.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/impl-bounds-checking.rs) <sup>unknown</sup>: traits (1.243), for (-0.999), shadowed (-0.999)
- [issues/issue-17718.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-17718.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/17718)</sup>: binding (1.236), consts (0.315), extern (-0.779)
- [issue-6157.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issue-6157.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/6157)</sup>: regions (1.213), unboxed-closures (-0.285), traits (-0.510)
- [issues/issue-44373.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-44373.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/44373)</sup>: consts (1.187), nll (0.427), borrowck (-0.704)
- [nullable-pointer-ffi-compat.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/nullable-pointer-ffi-compat.rs) <sup>unknown</sup>: regions (1.184), consts (0.650), traits (-0.571)
- [issues/issue-52992.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-52992.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/52992)</sup>: nll (1.132), associated-types (-0.628), parser (-0.893)
- [issues/issue-2330.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2330.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/2330)</sup>: traits (1.116), directory_ownership (-0.691), compare-method (-0.981)
- [issue-74047.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issue-74047.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/74047)</sup>: async-await (1.109), impl-trait (-0.629), resolve (-0.781)
- [issues/issue-33140.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33140.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/33140)</sup>: traits (1.063), coherence (-0.832), codemap_tests (-0.944)
- [issues/issue-28576.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-28576.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/28576)</sup>: traits (1.062), associated-types (-0.333), impl-trait (-0.697)
- [issues/issue-7222.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-7222.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/7222)</sup>: binding (1.062), consts (-0.226), numbers-arithmetic (-0.294)
- [tup.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/tup.rs) <sup>unknown</sup>: structs-enums (1.061), threads-sendsync (-0.550), moves (-0.790)
- [issues/issue-15261.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-15261.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/15261)</sup>: consts (1.052), where-clauses (-0.833), macros (-0.862)
- [issues/issue-76179.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-76179.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/76179)</sup>: associated-types (1.048), process (-0.887), rfc-2457 (-0.984)
- [issues/issue-42344.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-42344.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/42344)</sup>: borrowck (1.043), macros (-0.481), specialization (-0.966)
- [issues/issue-18661.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18661.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/18661)</sup>: unboxed-closures (1.038), mir (-0.648), higher-rank-trait-bounds (-0.688)
- [issues/issue-2633.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2633.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/2633)</sup>: structs-enums (1.020), functions-closures (-0.722), lint (-0.967)
Some notes:
- If there are related tests (e.g. it's for the same issue), they are moved along with it.
- Moved try-block.rs to the `try-block` dir.
- Moved tup.rs to the `tuple` dir.
- Moved some tests that classified as consts to the `statics` dir, as it seems they have statics actually.
- Skipped backtrace-debuginfo.rs because I think classifui overrates their helper macros.
cc #73494
r? ```@petrochenkov```
|
|
Fix diagnostic suggests adding type `[type error]`
Fixes #79040
### Unresolved questions:
<del>Why does this change output the diagnostic twice (`src/test/ui/79040.rs`)?</del> Thanks `````@oli-obk`````
|
|
|
|
|
|
Also don't push the paths on the stack directly in `fn parse_external_mod`, return them instead.
|
|
Fix #82524.
|
|
Fixes #79040
Unresolved questions:
Why does this change output the diagnostic twice?
Why does the CI fail when the errors are pointed out (UI tests)?
|
|
Add incomplete feature gate for inherent associate types.
Mentored by ``````@oli-obk``````
So far the only change is that instead of giving an automatic error, the following code compiles:
```rust
struct Foo;
impl Foo {
type Bar = isize;
}
```
The backend work to make it actually usable isn't there yet. In particular, this:
```rust
let x : Foo::Bar;
```
will give you:
```sh
error[E0223]: ambiguous associated type
--> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
|
LL | let x : Foo::Bar;
| ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
|
|
Suggest character encoding is incorrect when encountering random null bytes
This adds a note whenever null bytes are seen at the start of a token unexpectedly, since those tend to come from UTF-16 encoded files without a [BOM](https://en.wikipedia.org/wiki/Byte_order_mark) (if a UTF-16 BOM appears it won't be valid UTF-8, but if there is no BOM it be both valid UTF-16 and valid but garbled UTF-8). This approach was suggested in https://github.com/rust-lang/rust/issues/73979#issuecomment-653976451.
Closes #73979.
|
|
Reword labels on E0308 involving async fn return type
Fix for #80658.
When someone writes code like this:
```rust
fn foo() -> u8 {
async fn async_fn() -> () {}
async_fn()
}
```
And they try to compile it, they will see an error that looks like this:
```bash
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
2 | async fn async_fn() -> () {}
| -- checked the `Output` of this `async fn`, found opaque type
3 |
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found opaque type
|
= note: while checking the return type of this `async fn`
= note: expected type `u8`
found opaque type `impl Future`
```
|
|
fix the false 'defined here' messages
Closes #80853.
Take this code:
```rust
struct S;
fn repro_ref(thing: S) {
thing();
}
```
Previously, the error message would be this:
```
error[E0618]: expected function, found `S`
--> src/lib.rs:4:5
|
3 | fn repro_ref(thing: S) {
| ----- `S` defined here
4 | thing();
| ^^^^^--
| |
| call expression requires function
error: aborting due to previous error
```
This is incorrect as `S` is not defined in the function arguments, `thing` is defined there. With this change, the following is emitted:
```
error[E0618]: expected function, found `S`
--> $DIR/80853.rs:4:5
|
LL | fn repro_ref(thing: S) {
| ----- is of type `S`
LL | thing();
| ^^^^^--
| |
| call expression requires function
|
= note: local variable `S` is not a function
error: aborting due to previous error
```
As you can see, this error message points out that `thing` is of type `S` and later in a note, that `S` is not a function. This change does seem like a downside for some error messages. Take this example:
```
LL | struct Empty2;
| -------------- is of type `Empty2`
```
As you can see, the error message shows that the definition of `Empty2` is of type `Empty2`. Although this isn't wrong, it would be more helpful if it would say something like this (which was there previously):
```
LL | struct Empty2;
| -------------- `Empty2` defined here
```
If there is a better way of doing this, where the `Empty2` example would stay the same as without this change, please inform me.
**Update: This is now fixed**
CC `@camelid`
|
|
|
|
|
|
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
Suggest `return`ing tail expressions that match return type
Some newcomers are confused by the behavior of tail expressions,
interpreting that "leaving out the `;` makes it the return value".
To help them go in the right direction, suggest using `return` instead
when applicable.
|
|
Improve suggestion for tuple struct pattern matching errors.
Closes #80174
This change allows numbers to be parsed as field names when pattern matching on structs, which allows us to provide better error messages when tuple structs are matched using a struct pattern.
r? ``@estebank``
|
|
When a tail expression isn't unit, we previously always suggested adding
a trailing `;` to turn it into a statement. This suggestion isn't
appropriate for any expression that doesn't have side-effects, as the
user will have likely wanted to call something else or do something with
the resulting value, instead of just discarding it.
|
|
Some newcomers are confused by the behavior of tail expressions,
interpreting that "leaving out the `;` makes it the return value".
To help them go in the right direction, suggest using `return` instead
when applicable.
|
|
|
|
|
|
|
|
|
|
The panic happens when in recovery parsing a full `impl`
(`parse_item_impl`) fails and we drop the `DiagnosticBuilder` for the
recovery suggestion and return the `parse_item_impl` error.
We now raise the original error "expected identifier found `impl`" when
parsing the `impl` fails.
Note that the regression test is slightly simplified version of the
original repro in #81806, to make the error output smaller and more
resilient to unrelated changes in parser error messages.
Fixes #81806
|
|
|
|
|
|
|
|
|
|
Handle `Span`s for byte and raw strings and add more detail
CC #81208.
|
|
|
|
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>
|
|
|
|
|
|
Address comments
Update limits
|
|
|
|
|
|
Suggest async {} for async || {}
Fixes #76011
This adds support for adding help diagnostics to the feature gating checks and
then uses it for the async_closure gate to add the extra bit of help
information as described in the issue.
|
|
|
|
|
|
|
