| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This extends the `panic_fmt` lint to warn for all cases where the first
argument cannot be interpreted as a format string, as will happen in
Rust 2021.
It suggests to add `"{}", ` to format the message as a string. In the
case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.
It renames the lint to `non_fmt_panic` to match the lint naming
guidelines.
|
|
|
|
(Test was silently ignored on Linux CI prior to parent commit that switched to
using `# min-llvm-version`. But the switch made the ignoring stop, exposing
other brokenness in the form of bash-dependent syntax in the `$(shell ...)`
invocations.)
|
|
Fix panic when emitting diagnostic for closure mutable binding error
Fixes #81700
The upvar borrow kind may be `ty::BorrowKind::UniqueImmBorrow`, which is
still a mutable borrow for the purposes of this diagnostic code.
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #80394 (make const_err a future incompat lint)
- #81532 (Remove incorrect `delay_span_bug`)
- #81692 (Update clippy)
- #81715 (Reduce tab formatting assertions to debug only)
- #81716 (Fix non-existent-field ICE for generic fields.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix non-existent-field ICE for generic fields.
I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :)
This also changes one the field types in the related test to one that triggered the ICE.
Fixes #81627.
Fixes #81672.
Fixes #81709.
Cc https://github.com/rust-lang/rust/pull/81480 `@b-naber` `@estebank.`
|
|
Update clippy
r? `@flip1995`
|
|
Remove incorrect `delay_span_bug`
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix (but not close) #80207.
|
|
make const_err a future incompat lint
This is the first step for https://github.com/rust-lang/rust/issues/71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.
This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a *hard* error (at that point the error-on-use-site can be turned into a `delay_span_bug!` for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).
~~The one annoying effect of this PR is that `let _x = &(1/(1-1));` now also shows the future-incompat warning, even though of course we will *not* make this a hard error. We'll instead (hopefully) stop promoting it -- see https://github.com/rust-lang/rfcs/pull/3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".~~
Cc `@rust-lang/wg-const-eval`
|
|
Co-authored-by: eddyb <eddyb@lyken.rs>
|
|
Fixes #81700
The upvar borrow kind may be `ty::BorrowKind::UniqueImmBorrow`, which is
still a mutable borrow for the purposes of this diagnostic code.
|
|
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix #80207.
|
|
Co-Authored-By: Ashley Mannix <kodraus@hey.com>
|
|
Use ufcs in derive(Debug)
Cc #81211.
(Arguably this *is* the fix for it.)
|
|
|
|
|
|
Really fix early lints inside an async desugaring
Fixes #81531
cc `@Aaron1011`
r? `@petrochenkov`
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #81144 (Fixed formatting typo in map_while docs)
- #81573 (Add some links to the cell docs.)
- #81679 (Bind all clean::Type variants and remove FIXME)
- #81681 (Better styling of "Switch result tab" shortcut)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Better styling of "Switch result tab" shortcut
Before:
After:
|
|
r=poliorcetics,CraftSpider
Bind all clean::Type variants and remove FIXME
This is simply a little cleanup.
cc `@CraftSpider`
r? `@poliorcetics`
|
|
Add a new ABI to support cmse_nonsecure_call
This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.
See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).
This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).
On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
|
|
expression is a `const fn`
|
|
|
|
|
|
Update test-various to Ubuntu 20.04
The test command-setgroups.rs is adjusted to skip on musl, where `sysconf(_SC_NGROUPS_MAX)` always returns a dummy value of 32, even though the actual value is 65536. I'm not sure why this only became a problem now, as the information I found indicates that this value changed in kernel version 2.6.4, which is ages ago.
I'm a bit unsure whether this one will go through, because I locally also saw a failure in std-backtrace.rs which went away on subsequent runs, and also had port assignment failures, but I think those might be on my side. I'm kind of curious how the code in https://github.com/rust-lang/rust/blob/b122908617436af187252572ed5db96850551380/library/std/src/net/test.rs#L43-L56 is supposed to work, as the directory names it checks don't seem to appear anywhere else.
r? `@Mark-Simulacrum`
|
|
ad-hoc internal solution.
In particular: the specific code to define LLVM_VERSION_11_PLUS here was, for
some reason, using `$(shell ...)` with bash-specific variable replacement code.
On non-bash platforms like dash, that `shell` invocation would fail, and the
LLVM_VERSION_11_PLUS check would always fail, the test would always be ignored,
and thus be treated as a "success" (in the sense that `--bless` would never do
anything).
This was causing me a lot of pain.
|
|
We used to ignore `forbid(group)` scenarios completely. This changed
in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
|
|
Rollup of 14 pull requests
Successful merges:
- #80593 (Upgrade Chalk)
- #81260 (Add .editorconfig)
- #81455 (Add AArch64 big-endian and ILP32 targets)
- #81517 (Remove remnants of the santizer runtime crates from bootstrap)
- #81530 (sys: use `process::abort()` instead of `arch::wasm32::unreachable()`)
- #81544 (Add better diagnostic for unbounded Abst. Const)
- #81588 (Add doc aliases for "delete")
- #81603 (rustbuild: Don't build compiler twice for error-index-generator.)
- #81634 (Add long explanation e0521)
- #81636 (Directly use `Option<&[T]>` instead of converting from `Option<&Vec<T>>` later on)
- #81647 (Fix bug with assert!() calling the wrong edition of panic!().)
- #81655 (Improve wording of suggestion about accessing field)
- #81665 (Fix out of date `Scalar` documentation)
- #81671 (Add more associated type tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
The other two (`human` and `json`) are already handled.
|
|
Add more associated type tests
Closes #24159
Closes #37808
Closes #39532
Closes #37883
r? ``@estebank``
|
|
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.
|
|
r=GuillaumeGomez
Add long explanation e0521
Helps with #61137
|
|
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 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```
|
|
Remove remnants of the santizer runtime crates from bootstrap
|
|
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.
|
|
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.
|
|
|
|
|
