| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Perform coherence checking per impl.
r? `@ghost`
|
|
This greatly reduces round-trips to fetch relevant extra information about the
token in proc macro code, and avoids RPC messages to create Punct tokens.
|
|
|
|
Currently the generated code for methods like `eq`, `ne`, and `partial_cmp`
includes stuff like this:
```
let __self_vi = ::core::intrinsics::discriminant_value(&*self);
let __arg_1_vi = ::core::intrinsics::discriminant_value(&*other);
if true && __self_vi == __arg_1_vi {
...
}
```
This commit removes the unnecessary `true &&`, and makes the generating
code a little easier to read in the process. It also fixes some errors
in comments.
|
|
|
|
|
|
r=Mark-Simulacrum
Add regression test for #87558
Fixes #87558
|
|
Add a ui test for issue #91883
closes #91883
|
|
Add regression test for generic const in rustdoc
Fixes #92859.
r? ```@lcnr```
|
|
r=oli-obk
macros: use typed identifiers in diag and subdiag derive
Using typed identifiers instead of strings with the Fluent identifiers in the diagnostic and subdiagnostic derives - this enables the diagnostic derive to benefit from the compile-time validation that comes with typed identifiers, namely that use of a non-existent Fluent identifier will not compile.
r? `````@oli-obk`````
|
|
Transform help popup into a pocket menu
Just like we moved the settings menu into a "pocket menu", it's doing the same to the help popup.
You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot:
r? ``````````@jsha``````````
|
|
make const_err show up in future breakage reports
As tracked in https://github.com/rust-lang/rust/issues/71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since https://github.com/rust-lang/rust/pull/80394 (landed more than a year ago). Some CTFE errors are already hard errors since https://github.com/rust-lang/rust/pull/86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.
Cc `````@rust-lang/wg-const-eval`````
|
|
[rustc_parse] Forbid `let`s in certain places
Currently only forbids in locals to resolve https://github.com/rust-lang/rust/pull/94927#issuecomment-1099605024 but feel free to point any other places.
|
|
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
diagnostics: consider parameter count when suggesting smart pointers
Fixes #96834
|
|
Fix source sidebar hover in ayu theme
In the screenshot below, `rc.rs` should be orange:
It's because the CSS selector was not precise enough and was "overloaded" with another one. This PR fixes it and adds a test for the colors in the source sidebar.
cc `@jsha`
r? `@notriddle`
|
|
Fix backtrace UI test when panic=abort is used
The function `contains_verbose_expected` is only used when the panic strategy is not abort, so it caused a warning when it was abort, which made the UI test failed on stderr comparison.
|
|
Fix printing `impl trait` under binders
Before, we would render `impl for<'a> Trait<'a>` like `impl Trait<for<'a> 'a>`, lol.
|
|
compiletest: strip debuginfo by default for mode=ui
This reduces occupied disk space, for example for src/test/ui it drops from 1972mb to 132mb (x86_64-pc-windows-msvc).
Individual tests that require debuginfo/symbols should turn this option off (as in fixed tests).
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #96412 (Windows: Iterative `remove_dir_all`)
- #98126 (Mitigate MMIO stale data vulnerability)
- #98149 (Set relocation_model to Pic on emscripten target)
- #98194 (Leak pthread_{mutex,rwlock}_t if it's dropped while locked.)
- #98298 (Point to type parameter definition when not finding variant, method and associated item)
- #98311 (Reverse folder hierarchy)
- #98401 (Add tracking issues to `--extern` option docs.)
- #98429 (Use correct substs in enum discriminant cast)
- #98431 (Suggest defining variable as mutable on `&mut _` type mismatch in pats)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Suggest defining variable as mutable on `&mut _` type mismatch in pats
Suggest writing `mut a` where `&mut a` was written but a non-ref type provided.
Since we still don't have "apply either one of the suggestions but not both" kind of thing, the interaction with the suggestion of removing `&[mut]` or moving it to the type is weird, and idk how to make it better..
r? ``@compiler-errors``
|
|
Use correct substs in enum discriminant cast
Fixes https://github.com/rust-lang/rust/issues/97634
r? ```@lcnr```
|
|
r=compiler-errors
Point to type parameter definition when not finding variant, method and associated item
fixes #77391
|
|
Make RwLockReadGuard covariant
Hi, first time contributor here, if anything is not as expected, please let me know.
`RwLockReadGoard`'s type constructor is invariant. Since it behaves like a smart pointer to an immutable reference, there is no reason that it should not be covariant. Take e.g.
```
fn test_read_guard_covariance() {
fn do_stuff<'a>(_: RwLockReadGuard<'_, &'a i32>, _: &'a i32) {}
let j: i32 = 5;
let lock = RwLock::new(&j);
{
let i = 6;
do_stuff(lock.read().unwrap(), &i);
}
drop(lock);
}
```
where the compiler complains that &i doesn't live long enough. If `RwLockReadGuard` is covariant, then the above code is accepted because the lifetime can be shorter than `'a`.
In order for `RwLockReadGuard` to be covariant, it can't contain a full reference to the `RwLock`, which can never be covariant (because it exposes a mutable reference to the underlying data structure). By reducing the data structure to the required pieces of `RwLock`, the rest falls in place.
If there is a better way to do a test that tests successful compilation, please let me know.
Fixes #80392
|
|
|
|
|
|
|
|
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #91264 (Add macro support in jump to definition feature)
- #96955 (Remove (transitive) reliance on sorting by DefId in pretty-printer)
- #97633 (Session object: Set OS/ABI)
- #98039 (Fix `panic` message for `BTreeSet`'s `range` API and document `panic` cases)
- #98214 (rustc_target: Remove some redundant target properties)
- #98280 (Improve suggestion for calling fn-like expr on type mismatch)
- #98394 (Fixup missing renames from `#[main]` to `#[rustc_main]`)
- #98411 (Update tendril)
- #98419 (Remove excess rib while resolving closures)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
As in the diagnostic derive, using typed identifiers in the
subdiagnostic derive improves the diagnostics of using the subdiagnostic
derive as Fluent messages will be confirmed to exist at compile-time.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Using typed identifiers instead of strings with the Fluent identifier
enables the diagnostic derive to benefit from the compile-time
validation that comes with typed identifiers - use of a non-existent
Fluent identifier will not compile.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
r=estebank
Improve suggestion for calling fn-like expr on type mismatch
1.) Suggest calling values of with RPIT types (and probably TAIT) when we expect `Ty` and have `impl Fn() -> Ty`
2.) Suggest calling closures even when they're not assigned to a local variable first
3.) Drive-by fix of a pretty-printing bug (`impl Fn()-> Ty` => `impl Fn() -> Ty`)
r? ```@estebank```
|
|
Remove (transitive) reliance on sorting by DefId in pretty-printer
This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See #90317
|
|
Add macro support in jump to definition feature
Fixes #91174.
To do so, I check if the span comes from an expansion, and if so, I infer the original macro `DefId` or `Span` depending if it's a defined in the current crate or not.
There is one limitation due to macro expansion though:
```rust
macro_rules! yolo { () => {}}
fn foo() {
yolo!();
}
```
In `foo`, `yolo!` won't be linked because after expansion, it is replaced by nothing (which seems logical). So I can't get an item from the `Visitor` from which I could tell if its `Span` comes from an expansion.
I added a test for this specific limitation alongside others.
Demo: https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html
As for the empty macro issue that cannot create a jump to definition, you can see it [here](https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html#35).
r? ```@jyn514```
|
|
fix universes in the NLL type tests
In the NLL code, we were not accommodating universes in the
`type_test` logic.
Fixes #98095.
r? `@compiler-errors`
This breaks some tests, however, so the purpose of this branch is more explanatory and perhaps to do a crater run.
|
