| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 1eeb8e8b151d1da7daa73837a25dc5f7a1a7fa28, reversing
changes made to 324bf2b9fd8bf9661e7045c8a93f5ff0ec1a8ca5.
Unfortunately the assert desugaring change is not backwards compatible,
see RUST-145770.
Code such as
```rust
#[derive(Debug)]
struct F {
data: bool
}
impl std::ops::Not for F {
type Output = bool;
fn not(self) -> Self::Output { !self.data }
}
fn main() {
let f = F { data: true };
assert!(f);
}
```
would be broken by the assert desugaring change. We may need to land
the change over an edition boundary, or limit the editions that the
desugaring change impacts.
|
|
Strip frontmatter in fewer places
* Stop stripping frontmatter in `proc_macro::Literal::from_str` (RUST-146132)
* Stop stripping frontmatter in expr-ctxt (but not item-ctxt!) `include`s (RUST-145945)
* Stop stripping shebang (!) in `proc_macro::Literal::from_str`
* Not a breaking change because it did compare spans already to ensure there wasn't extra whitespace or comments (`Literal::from_str("#!\n0")` already yields `Err(_)` thankfully!)
* Stop stripping frontmatter+shebang inside some rustdoc code where it doesn't make any observable difference (see self review comments)
* (Stop stripping frontmatter+shebang inside internal test code)
Fixes https://github.com/rust-lang/rust/issues/145945.
Fixes https://github.com/rust-lang/rust/issues/146132.
r? fee1-dead
|
|
|
|
|
|
|
|
|
|
|
|
Stop calling unwrap when format foreign has trailing dollar
Fixes rust-lang/rust#137580
|
|
|
|
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
|
|
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
|
|
|
|
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#145538 (bufreader::Buffer::backshift: don't move the uninit bytes)
- rust-lang/rust#145542 (triagebot: Don't warn no-mentions on subtree updates)
- rust-lang/rust#145549 (Update rust maintainers in openharmony.md)
- rust-lang/rust#145550 (Avoid using `()` in `derive(From)` output.)
- rust-lang/rust#145556 (Allow stability attributes on extern crates)
- rust-lang/rust#145560 (Remove unused `PartialOrd`/`Ord` from bootstrap)
- rust-lang/rust#145568 (ignore frontmatters in `TokenStream::new`)
- rust-lang/rust#145571 (remove myself from some adhoc-groups and pings)
- rust-lang/rust#145576 (Add change tracker entry for `--timings`)
- rust-lang/rust#145578 (Add VEXos "linked files" support to `armv7a-vex-v5`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
|
|
Couple of codegen_fn_attrs improvements
As noted in https://github.com/rust-lang/rust/pull/144678#discussion_r2245060329 here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
|
|
Using an error type instead of `()` avoids the duplicated errors
on `struct SUnsizedField` in `deriving-from-wrong-target.rs`. It also
improves the expanded output from this:
```
struct S2(u32, u32);
impl ::core::convert::From<()> for S2 {
#[inline]
fn from(value: ()) -> S2 { (/*ERROR*/) }
}
```
to this:
```
struct S2(u32, u32);
impl ::core::convert::From<(/*ERROR*/)> for S2 {
#[inline]
fn from(value: (/*ERROR*/)) -> S2 { (/*ERROR*/) }
}
```
The new code also only matchs on `item.kind` once.
|
|
Implement `#[derive(From)]`
Implements the `#[derive(From)]` feature ([tracking issue](https://github.com/rust-lang/rust/issues/144889), [RFC](https://github.com/rust-lang/rfcs/pull/3809)).
It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
|
|
|
|
|
|
|
|
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
|
|
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
|
|
|
|
|
|
|
|
|
|
In the desugaring of `assert!`, we now expand to a `match` expression
instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not
the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
`assert!(val)` now desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix #122159.
We make some minor changes to some diagnostics to avoid span overlap on
type mismatch or inverted "expected"/"found" on type errors.
We remove some unnecessary parens from core, alloc and miri.
address review comments
|
|
Tweak invalid builtin attribute output
- Add link to reference/docs when possible
- More accurate suggestions by supporting multiple alternative suggestions
```
error: malformed `crate_type` attribute input
--> $DIR/crate-type-macro-call.rs:1:1
|
LL | #![crate_type = foo!()]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit <https://doc.rust-lang.org/reference/linkage.html>
help: the following are the possible correct uses
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "bin"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "cdylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "dylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "lib"]
|
= and 4 other candidates
```
|
|
|
|
`NamedValueStr`
Modify `AttributeTemplate` to support list of alternatives for list and name value attribute styles.
Suggestions now provide more correct suggested code:
```
error[E0805]: malformed `used` attribute input
--> $DIR/used_with_multi_args.rs:3:1
|
LL | #[used(compiler, linker)]
| ^^^^^^------------------^
| |
| expected a single argument here
|
help: try changing it to one of the following valid forms of the attribute
|
LL - #[used(compiler, linker)]
LL + #[used(compiler)]
|
LL - #[used(compiler, linker)]
LL + #[used(linker)]
|
LL - #[used(compiler, linker)]
LL + #[used]
|
```
instead of the prior "masking" of the lack of this feature by suggesting pipe-separated lists:
```
error[E0805]: malformed `used` attribute input
--> $DIR/used_with_multi_args.rs:3:1
|
LL | #[used(compiler, linker)]
| ^^^^^^------------------^
| |
| expected a single argument here
|
help: try changing it to one of the following valid forms of the attribute
|
LL - #[used(compiler, linker)]
LL + #[used(compiler|linker)]
|
LL - #[used(compiler, linker)]
LL + #[used]
|
```
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Make slice comparisons const
This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.
r? ```@fee1-dead```
cc rust-lang/rust#143800
|
|
Also make it *only* usable on nightly
|
|
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
|
|
Rollup of 13 pull requests
Successful merges:
- rust-lang/rust#142301 (tests: Fix duplicated-path-in-error fail with musl)
- rust-lang/rust#143630 (Drop `./x suggest`)
- rust-lang/rust#143736 (Give all bytes of TypeId provenance)
- rust-lang/rust#143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler)
- rust-lang/rust#143837 (Adjust `run_make_support::symbols` helpers)
- rust-lang/rust#143878 (Port `#[pointee]` to the new attribute parsing infrastructure)
- rust-lang/rust#143905 (Recover and suggest to use `;` to construct array type)
- rust-lang/rust#143907 (core: make `str::split_at_unchecked()` inline)
- rust-lang/rust#143910 (Add experimental `backtrace-trace-only` std feature)
- rust-lang/rust#143927 (Preserve constness in trait objects up to hir ty lowering)
- rust-lang/rust#143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself)
- rust-lang/rust#143938 (Update books)
- rust-lang/rust#143941 (update `cfg_select!` documentation)
Failed merges:
- rust-lang/rust#143926 (Remove deprecated fields in bootstrap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
and make internal terminology consistent
Co-authored-by: Travis Cross <tc@traviscross.com>
|
|
|
|
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
|
|
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
rustc_builtin_macros: Make sure registered attributes stay sorted
As with the list of builtin macros, use tidy to make sure the list of
builtin attributes stays sorted.
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
As with the list of builtin macros, use tidy to make sure the list of
builtin attributes stays sorted.
|
|
Replace kw_span by full span for generic const parameters.
Small simplification extracted from https://github.com/rust-lang/rust/pull/127241
|
