Improve wording of suggestion about accessing field
Follow-up to #81504
The compiler at this moment suggests "you might have meant to use field `b` of type `B`", sounding like it's type `B` which has the field `b`.
r? ```@estebank```
Fix bug with assert!() calling the wrong edition of panic!().
The span of `panic!` produced by the `assert` macro did not carry the right edition. This changes `assert` to call the right version.
Also adds tests for the 2021 edition of panic and assert, that would've caught this.
rustbuild: Don't build compiler twice for error-index-generator.
When using `--stage=1`, the error-index-generator was forcing the compiler to be built twice. This isn't necessary; the error-index-generator just needs the same unusual logic that rustdoc uses to build with stage minus one.
`--stage=0` and `--stage=2` should be unaffected by this change.
cc #76371
Add doc aliases for "delete"
This patch adds doc aliases for "delete". The added aliases are supposed to reference usages `delete` in other programming languages.
- `HashMap::remove`, `BTreeMap::remove` -> `Map#delete` and `delete` keyword in JavaScript.
- `HashSet::remove`, `BTreeSet::remove` -> `Set#delete` in JavaScript.
- `mem::drop` -> `delete` keyword in C++.
- `fs::remove_file`, `fs::remove_dir`, `fs::remove_dir_all`-> `File#delete` in Java, `File#delete` and `Dir#delete` in Ruby.
Before this change, searching for "delete" in documentation returned no results.
Add better diagnostic for unbounded Abst. Const
~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst<const_fn(N)>: ,`,
instead of requiring a where bound, just check that only consts are being substituted in to skip over where check.~~
~~This is pretty sketchy, but I think it works. Presumably, if there is checking for type bounds added later, it can first check nested requirements, and see if they're satisfied by the current `ParamEnv`.~~
Changed the diagnostic to add a better example, which is more practical than what was previously proposed.
r? ```@lcnr```
sys: use `process::abort()` instead of `arch::wasm32::unreachable()`
Rationale:
- `abort()` lowers to `wasm32::unreachable()` anyway.
- `abort()` isn't `unsafe`.
- `abort()` matches the comment better.
- `abort()` avoids confusion by future readers (e.g. https://github.com/rust-lang/rust/pull/81527): the naming of wasm's `unreachable` instruction is a bit unfortunate because it is not related to the `unreachable()` intrinsic (intended to trigger UB).
Codegen is likely to be different since `unreachable()` is `inline` while `abort()` is `cold`. Since it doesn't look like we are expecting here to trigger this case, the latter seems better anyway.
Add AArch64 big-endian and ILP32 targets
This PR adds 3 new AArch64 targets:
- `aarch64_be-unknown-linux-gnu`
- `aarch64-unknown-linux-gnu_ilp32`
- `aarch64_be-unknown-linux-gnu_ilp32`
It also fixes some ABI issues on big-endian ARM and AArch64.
Add .editorconfig
This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Add .editorconfig
This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Upgrade Chalk
~~Blocked on rust-lang/chalk#670~~
~~Now blocked on rust-lang/chalk#680 and release~~
In addition to the straight upgrade, I also tried to fix some tests by properly returning variables and max universes in the solution. Unfortunately, this actually triggers the same perf problem that rustc traits code runs into in `canonicalizer`. Not sure what the root cause of this problem is, or why it's supposed to be solved in chalk.
r? ```@nikomatsakis```
Fix early lints inside an async desugaring
Fixes#81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the NodeId of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that NodeId does not actually exist in the AST.
This commit uses the parent of a desugared closure when computing
`lint_node_id`, which is something that actually exists in the AST (an
`async fn` or async closure).
Fixes#81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the `NodeId` of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that `NodeId` does not actually exist in the AST.
This commit explicitly calls `check_lint` for the `NodeId`s of closures
desugared from async expressions, ensuring that we do not miss any
buffered lints.
Updated some NITs in the documentation from #6630
I've implemented the two suggestions from #6630 that were added after the merge. This PR also changes the example code to use `register_*_pass` instead of `register_late_pass`. I'm not sure if this is better or worse, but it makes it clearer in my opinion. Let me know if I should change it back.
---
changelog: none
r? `@flip1995`
Box the biggest ast::ItemKind variants
This PR is a different approach on https://github.com/rust-lang/rust/pull/81400, aiming to save memory in humongous ASTs.
The three affected item kind enums are:
- `ast::ItemKind` (208 -> 112 bytes)
- `ast::AssocItemKind` (176 -> 72 bytes)
- `ast::ForeignItemKind` (176 -> 72 bytes)
Box the biggest ast::ItemKind variants
This PR is a different approach on https://github.com/rust-lang/rust/pull/81400, aiming to save memory in humongous ASTs.
The three affected item kind enums are:
- `ast::ItemKind` (208 -> 112 bytes)
- `ast::AssocItemKind` (176 -> 72 bytes)
- `ast::ForeignItemKind` (176 -> 72 bytes)
Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.
https://editorconfig.org/
Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.
https://editorconfig.org/
Add new lint "missing_panics_doc"
fixes#1974
changelog: Added the "missing_panics_doc" lint which lints when public functions that may panic are missing "# Panics" in their doc comment
Fix let_and_return false positive
The issue:
See this Rust playground link: https://play.rust-lang.org/?edition=2018&gist=12cb5d1e7527f8c37743b87fc4a53748
Run the above with clippy to see the following warning:
```
warning: returning the result of a `let` binding from a block
--> src/main.rs:24:5
|
23 | let value = Foo::new(&x).value();
| --------------------------------- unnecessary `let` binding
24 | value
| ^^^^^
|
= note: `#[warn(clippy::let_and_return)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
|
23 |
24 | Foo::new(&x).value()
|
```
Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:
```
error[E0597]: `x` does not live long enough
--> src/main.rs:23:14
|
23 | Foo::new(&x).value()
| ---------^^-
| | |
| | borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
24 | }
| -
| |
| `x` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
|
= note: the temporary is part of an expression at the end of a block;
consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
|
23 | let x = Foo::new(&x).value(); x
| ^^^^^^^ ^^^
```
The fix:
Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.
changelog: none
Remove unneeded `mut` variable
`arg_elide` gets initialized, immediately cloned, and only written to after that.
The last reading access was removed back in
7704762604
Remove the remains of query categories
Back in October 2020 in #77830 ``@cjgillot`` removed the query categories information from the profiler, but the actual definitions which query was in which category remained, although unused.
Here I clean that up, to simplify the query definitions even further.
It's unfortunate that this loses all the context for `git blame`, ~~but I'm working on moving those query definitions into `rustc_query_system`, which will lose that context anyway.~~ EDIT: Might not work out.
The functional changes are in the first commit. The second one only changes the indentation.
Improve handling of spans around macro result parse errors
Fixes#81543
After we expand a macro, we try to parse the resulting tokens as a AST
node. This commit makes several improvements to how we handle spans when
an error occurs:
* Only ovewrite the original `Span` if it's a dummy span. This preserves
a more-specific span if one is available.
* Use `self.prev_token` instead of `self.token` when emitting an error
message after encountering EOF, since an EOF token always has a dummy
span
* Make `SourceMap::next_point` leave dummy spans unused. A dummy span
does not have a logical 'next point', since it's a zero-length span.
Re-using the span span preserves its 'dummy-ness' for other checks
rustdoc: Note why `rustdoc::html::markdown` is public
Almost all of the modules are crate-private, except for
`rustdoc::json::types`, which I believe is intended to be for public
use; and `rustdoc::html::markdown`, which is used externally by the
error-index generator and so has to be public.
r? ``@GuillaumeGomez``
Add some tests for associated-type-bounds issues
Closes#38917Closes#40093Closes#43475Closes#63591#47897 is likely closable too, but it needs an MCVE
~~#38917, #40093, #43475, #47897 all are mislabeled and shouldn't have the `F-associated-type-bounds` label~~
~~#71685 is also mislabeled as commented on in that thread~~
