| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Revert "Add missing brace"
This reverts commit 85ad773049536d7fed9a94ae0ac74f97135c8655.
Revert "Simplify base_expr"
This reverts commit 899aae465eb4ef295dc1eeb2603f744568e0768c.
Revert "Warn write-only fields"
This reverts commit d3c69a4c0dd98af2611b7553d1a65afef6a6ccb0.
|
|
Fix #82455.
(cherry picked from commit 5ad60888275852136adea38aebc7fcce69b52474)
|
|
It should be never break another crate to re-export a public item.
Note that this doesn't check the feature gate at
*all* for other crates:
- Feature-gates aren't currently serialized, so the only way to check
the gate is with ad-hoc attribute checking.
- Checking the feature gate twice (once when documenting the original
crate and one when documenting the current crate) seems not great.
This should still catch using the feature most of the time though, since
people tend to document their own crates.
(cherry picked from commit fdb32e997bef725f538f66dcfd96b1c1e51d2c56)
|
|
Fixes #82156
(cherry picked from commit 9889e44470cbc6ae3c8e2fcfb6016ed15ed8cf51)
|
|
|
|
|
|
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
|
|
|
|
Never MIR inline functions with a different instruction set
|
|
Make rustdoc respect `--error-format short` in doctests
Note that this will not work with `cargo test`, only with `rustdoc --test`, I'll have to modify `cargo` as well.
Fix #81662.
`@rustbot` label +T-rustdoc +A-doctests
|
|
pnkfelix:issue-80949-short-term-resolution-via-revert-of-pr-78373, r=matthewjasper
Revert 78373 ("dont leak return value after panic in drop")
Short term resolution for issue #80949.
Reopen #47949 after this lands.
(We plan to fine-tune PR #78373 to not run into this problem.)
|
|
Make `Allocator` object-safe
This allows rust-lang/wg-allocators#83: polymorphic allocators
|
|
Remove struct_type from union output
Also bumps the format number and adds a test
Rationale: It's illegal to have unions of the form `union Union(i32, f32);`, or `union Union;`. The struct_type field was recently removed from the rustdoc Union AST, at which time this field was changed to always just read "union". It makes sense to completely remove it, as it provides no information.
|
|
rustdoc-json: Fix has_body
Previously, `has_body` was always true. Now propagate the type of the method to set it correctly. Relies on #81287, that will need to be merged first.
|
|
Handle `Span`s for byte and raw strings and add more detail
CC #81208.
|
|
relax adt unsizing requirements
Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change.
This change is currently insta stable and changes the language, so it at least requires a lang fcp. I feel like the current state is fairly unintuitive.
An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967
```rust
struct A<T, U: ?Sized>(T, B<T, U>); // previously ERR
// struct A<T, U: ?Sized>(T, B<[u32; 1], U>); // ok
struct B<T, U: ?Sized>(T, U);
fn main() {
let x = A([0; 1], B([0; 1], [0; 1]));
let y: &A<[u32; 1], [u32]> = &x;
assert_eq!(y.1.1.len(), 1);
}
```
|
|
r=jackh726
Generic associated types in trait paths
This is the second part of https://github.com/rust-lang/rust/pull/78978
This should fix:
Fixes #67510
Fixes #68648
Fixes #68649
Fixes #68650
Fixes #68652
Fixes #74684
Fixes #76535
Fixes #79422
Fixes #80433
and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265
r? ``@matthewjasper``
|
|
r=simulacrum
Use `# min-llvm-version: 11.0` to force a minimum LLVM version
Use `# min-llvm-version: 11.0` to force a minimum LLVM version, rather than 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).
* Note in particular that GNU Make treats the SHELL variable as a very special case: it does not inherit the value of SHELL from the user's environment. Except on Windows. See more explanation in the [GNU Make docs](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html).
* The effect of this is that these tests end up using `/bin/sh` (except on Windows) for their `$(shell ...)` invocations, and thus we see differing behaviors depending on whether your `/bin/sh` links to `/bin/dash` or to `/bin/bash`.
This was causing me a lot of pain.
|
|
|
|
|
|
This reverts commit b766abc88f78f36193ddefb1079dbc832346b358.
|
|
This reverts commit 7f3e8551dde7f14641618cdb8fda2f99ff1d74b6.
|
|
This reverts commit 4fef39113a514bb270f5661a82fdba17d3e41dbb.
|
|
|
|
|
|
Move test to be with the others
No functional changes. I just created this test in the wrong place in a past PR. All of the other or-pattern tests are in the `or-patterns` directory.
|
|
Add lint for `panic!(123)` which is not accepted in Rust 2021.
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.
This is part of #80162.
r? ```@estebank```
|
|
introduce future-compatibility warning for forbidden lint groups
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.
r? ``@Mark-Simulacrum``
|
|
Stabilize the Wake trait
This PR proposes stabilizing the `wake_trait` feature, tracking issue https://github.com/rust-lang/rust/issues/69912.
## Motivation
The surface area this trait introduces is small, and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this.
Personally I would love to have this available on stable, since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended.
## Implementation notes
This PR itself fixes a link in the docs, and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting, but is intended to serve as a teaching device for both `task::Wake` and futures alike.
|
|
|
|
add test to ensure object-safety
This allows for runtime polymorphic allocators
|
|
|
|
|
|
|
|
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.`
|
|
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.)
|
|
|
