| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rename environment variable for overriding rustc version
|
|
r=Aaron1011
Implement `#[rustc_must_implement_one_of]` attribute
This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the "minimal complete definition" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma, though `#[rustc_must_implement_one_of]` is weaker atm.
Such attribute was long wanted. It can be, for example, used in `Read` trait to make transitions to recently added `read_buf` easier:
```rust
#[rustc_must_implement_one_of(read, read_buf)]
pub trait Read {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> {
let mut buf = ReadBuf::new(buf);
self.read_buf(&mut buf)?;
Ok(buf.filled_len())
}
fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> {
default_read_buf(|b| self.read(b), buf)
}
}
impl Read for Ty0 {}
//^ This will fail to compile even though all `Read` methods have default implementations
// Both of these will compile just fine
impl Read for Ty1 {
fn read(&mut self, buf: &mut [u8]) -> Result<usize> { /* ... */ }
}
impl Read for Ty2 {
fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ }
}
```
For now, this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it:
- Allow arbitrary requirements like `a | (b & c)`
- Allow multiple requirements like
- ```rust
#[rustc_must_implement_one_of(a, b)]
#[rustc_must_implement_one_of(c, d)]
```
- Make it appear in rustdoc documentation
- Change the syntax?
- Etc
Eventually, we should make an RFC and make this (or rather similar) attribute public.
---
I'm fairly new to compiler development and not at all sure if the implementation makes sense, but at least it passes tests :)
|
|
Remove deprecated LLVM-style inline assembly
The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.
Closes #70173.
Closes #92794.
Closes #87612.
Closes #82065.
cc `@rust-lang/wg-inline-asm`
r? `@Amanieu`
|
|
Rollup of 10 pull requests
Successful merges:
- #92795 (Link sidebar "location" heading to top of page)
- #92799 (Remove some unnecessary uses of `FieldDef::ident`)
- #92808 (Fix `try wrapping expression in variant` suggestion with struct field shorthand)
- #92819 (rustdoc: remove hand-rolled isatty)
- #92876 (Fix suggesting turbofish with lifetime arguments)
- #92921 (Rename Printer constructor from mk_printer() to Printer::new())
- #92937 (rustdoc: Add missing dot separator)
- #92953 (Copy an example to PartialOrd as well)
- #92977 (Docs: recommend VecDeque instead of Vec::remove(0))
- #92981 (fix const_ptr_offset_from tracking issue)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: Add missing dot separator
Fixes #92901.
r? ``@jsha``
|
|
r=nagisa
Fix suggesting turbofish with lifetime arguments
Now we suggest turbofish correctly given exprs like `foo<'_>`.
Also fix suggestion when we have `let x = foo<bar, baz>;` which was broken.
|
|
compiler-errors:wrap-struct-shorthand-field-in-variant, r=davidtwco
Fix `try wrapping expression in variant` suggestion with struct field shorthand
Fixes a broken suggestion: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=83fe2dbfe1485f8cfca1aef2a6582e77)
before:
```
error[E0308]: mismatched types
--> src/main.rs:7:19
|
7 | let x = Foo { bar };
| ^^^ expected enum `Option`, found integer
|
= note: expected enum `Option<i32>`
found type `{integer}`
help: try wrapping the expression in `Some`
|
7 | let x = Foo { Some(bar) };
| +++++ +
```
after:
```
error[E0308]: mismatched types
--> src/main.rs:7:19
|
7 | let x = Foo { bar };
| ^^^ expected enum `Option`, found integer
|
= note: expected enum `Option<i32>`
found type `{integer}`
help: try wrapping the expression in `Some`
|
7 | let x = Foo { bar: Some(bar) };
| ~~~~~~~~~~~~~~
```
r? ``@m-ou-se``
since you touched the code last in #91080
|
|
Link sidebar "location" heading to top of page
This makes it easy, when you are scrolled far down in a page, to jump back to the top.
Demo: https://rustdoc.crud.net/jsha/link-to-top/std/string/struct.String.html
r? ``@GuillaumeGomez``
|
|
expand: Pick `cfg`s and `cfg_attrs` one by one, like other attributes
This is a rebase of https://github.com/rust-lang/rust/pull/83354, but without any language-changing parts ~(except for https://github.com/rust-lang/rust/pull/84110)~, i.e. the attribute expansion order is the same.
This is a pre-requisite for any other changes making cfg attributes closer to regular macro attributes
- Possibly changing their expansion order (https://github.com/rust-lang/rust/issues/83331)
- Keeping macro backtraces for cfg attributes, or otherwise making them visible after expansion without keeping them in place literally (https://github.com/rust-lang/rust/pull/84110).
Two exceptions to the "one by one" behavior are:
- cfgs eagerly expanded by `derive` and `cfg_eval`, they are still expanded in a batch, that's by design.
- cfgs at the crate root, they are currently expanded not during the main expansion pass, but before that, during `#![feature]` collection. I'll try to disentangle that logic later in a separate PR.
r? `@Aaron1011`
|
|
rustdoc: fix intra-link for generic trait impls
fixes #92662
r? `````@camelid`````
|
|
Parse `Ty?` as `Option<Ty>` and provide structured suggestion
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
|
|
Include Projections when elaborating TypeOutlives
Fixes #92280
In `Elaborator`, we elaborate that `Foo<<Bar as Baz>::Assoc>: 'a` -> `<Bar as Baz>::Assoc: 'a`. This is the same rule that would be applied to any other `Param`. If there are escaping vars, we continue to do nothing.
r? `@nikomatsakis`
|
|
feat: rustc_pass_by_value lint attribute
Useful for thin wrapper attributes that are best passed as value instead
of reference.
Fixes #76935
|
|
rustdoc: Yet more intra-doc links cleanup
r? `@Manishearth`
|
|
Fix unclosed boxes in pretty printing of TraitAlias
This was causing trait aliases to not even render at all in stringified / pretty printed output.
```rust
macro_rules! repro {
($item:item) => {
stringify!($item)
};
}
fn main() {
println!("{:?}", repro!(pub trait Trait<T> = Sized where T: 'a;));
}
```
Before: `""`
After: `"pub trait Trait<T> = Sized where T: 'a;"`
The fix is copied from how `head`/`end` for `ItemKind::Use`, `ItemKind::ExternCrate`, and `ItemKind::Mod` are all done in the pretty printer:
https://github.com/rust-lang/rust/blob/dd3ac41495e85a9b7b5cb3186379d02ce17e51fe/compiler/rustc_ast_pretty/src/pprust/state.rs#L1178-L1184
|
|
partially revertish `lazily "compute" anon const default substs`
reverts #87280 except for some of the changes around `ty::Unevaluated` having a visitor and a generic for promoted
why revert: <https://github.com/rust-lang/rust/pull/92805#issuecomment-1010736049>
r? `@lcnr`
|
|
|
|
Implement `panic::update_hook`
Add a new function `panic::update_hook` to allow creating panic hooks that forward the call to the previously set panic hook, without race conditions. It works by taking a closure that transforms the old panic hook into a new one, while ensuring that during the execution of the closure no other thread can modify the panic hook. This is a small function so I hope it can be discussed here without a formal RFC, however if you prefer I can write one.
Consider the following example:
```rust
let prev = panic::take_hook();
panic::set_hook(Box::new(move |info| {
println!("panic handler A");
prev(info);
}));
```
This is a common pattern in libraries that need to do something in case of panic: log panic to a file, record code coverage, send panic message to a monitoring service, print custom message with link to github to open a new issue, etc. However it is impossible to avoid race conditions with the current API, because two threads can execute in this order:
* Thread A calls `panic::take_hook()`
* Thread B calls `panic::take_hook()`
* Thread A calls `panic::set_hook()`
* Thread B calls `panic::set_hook()`
And the result is that the original panic hook has been lost, as well as the panic hook set by thread A. The resulting panic hook will be the one set by thread B, which forwards to the default panic hook. This is not considered a big issue because the panic handler setup is usually run during initialization code, probably before spawning any other threads.
Using the new `panic::update_hook` function, this race condition is impossible, and the result will be either `A, B, original` or `B, A, original`.
```rust
panic::update_hook(|prev| {
Box::new(move |info| {
println!("panic handler A");
prev(info);
})
});
```
I found one real world use case here: https://github.com/dtolnay/proc-macro2/blob/988cf403e741aadfd5340bbf67e35e1062a526aa/src/detection.rs#L32 the workaround is to detect the race condition and panic in that case.
The pattern of `take_hook` + `set_hook` is very common, you can see some examples in this pull request, so I think it's natural to have a function that combines them both. Also using `update_hook` instead of `take_hook` + `set_hook` reduces the number of calls to `HOOK_LOCK.write()` from 2 to 1, but I don't expect this to make any difference in performance.
### Unresolved questions:
* `panic::update_hook` takes a closure, if that closure panics the error message is "panicked while processing panic" which is not nice. This is a consequence of holding the `HOOK_LOCK` while executing the closure. Could be avoided using `catch_unwind`?
* Reimplement `panic::set_hook` as `panic::update_hook(|_prev| hook)`?
|
|
|
|
|
|
Link impl items to corresponding trait items in late resolver.
Hygienically linking trait impl items to declarations in the trait can be done directly by the late resolver. In fact, it is already done to diagnose unknown items.
This PR uses this resolution work and stores the `DefId` of the trait item in the HIR. This avoids having to do this resolution manually later.
r? `@matthewjasper`
Related to #90639. The added `trait_item_id` field can be moved to `ImplItemRef` to be used directly by your PR.
|
|
r=fee1-dead
Do not fail evaluation in const blocks
Evaluate const blocks with a const param-env, so we properly check `~const` trait bounds.
Fixes #92713
(I will fix the poor diagnostics in #92713 and #92712 in a separate PR)
cc `@nbdd0121` who wrote the code this PR touches in #89561
|
|
Generate more precise generator names
Currently all generators are named with a `generator$N` suffix, regardless of where they come from. This means an `async fn` shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators.
This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator.
r? `@tmandry`
cc `@michaelwoerister` `@wesleywiser` `@dpaoliello`
|
|
Ignore static lifetimes for GATs outlives lint
cc https://github.com/rust-lang/rust/issues/87479#issuecomment-1010484170
Also included a bit of cleanup of `ty_known_to_outlive` and `region_known_to_outlive`
r? `@nikomatsakis`
|
|
|
|
|
|
Make `opt_const_param_of` work in the presence of `GenericArg::Infer`
highly recommend viewing the first and second commits on their own rather than looking at file changes :rofl:
Because we filtered args down to just const args we would ignore `GenericArg::Infer` which made us get a `arg_index` which was wrong by however many const `GenericArg::Infer` came previously
[example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=46dba6a53aca6333028a10908ef16e0b) of the [bugs](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a8eebced26eefa4119fc2e7ae0c76de6) fixed.
r? ```@lcnr```
|
|
Prefer projection candidates instead of param_env candidates for Sized predicates
Fixes #89352
Also includes some drive by logging and verbose printing changes that I found useful when debugging this, but I can remove this if needed.
This is a little hacky - but imo no more than the rest of `candidate_should_be_dropped_in_favor_of`. Importantly, in a Chalk-like world, both candidates should be completely compatible.
r? ```@nikomatsakis```
|
|
|
|
|
|
This makes it easy, when you are scrolled far down in a page, to jump
back to the top.
|
|
Rollup of 9 pull requests
Successful merges:
- #92045 (Don't fall back to crate-level opaque type definitions.)
- #92381 (Suggest `return`ing tail expressions in async functions)
- #92768 (Partially stabilize `maybe_uninit_extra`)
- #92810 (Deduplicate box deref and regular deref suggestions)
- #92818 (Update documentation for doc_cfg feature)
- #92840 (Fix some lints documentation)
- #92849 (Clippyup)
- #92854 (Use the updated Rust logo in rustdoc)
- #92864 (Fix a missing dot in the main item heading)
Failed merges:
- #92838 (Clean up some links in RELEASES)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
r=camelid
Deduplicate box deref and regular deref suggestions
Remove the suggestion code special-cased for Box deref.
r? ```@camelid```
since you introduced the code in #90627
|
|
Suggest `return`ing tail expressions in async functions
This PR fixes #92308.
Previously, the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions, as the suggestion checked whether the types were equal disregarding `impl Future<Output = T>` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut.
I'm not sure if this is the "right" way to do this, so if there is a better way then please let me know.
I amended an existing test introduced in #81769 to add a regression test for this, if you think I should make a separate test I will.
|
|
Set struct/union/enum fields/variants as reachable when item is
Fixes #92755
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #90001 (Make rlib metadata strip works with MIPSr6 architecture)
- #91687 (rustdoc: do not emit tuple variant fields if none are documented)
- #91938 (Add `std::error::Report` type)
- #92006 (Welcome opaque types into the fold)
- #92142 ([code coverage] Fix missing dead code in modules that are never called)
- #92277 (rustc_metadata: Stop passing `CrateMetadataRef` by reference (step 1))
- #92334 (rustdoc: Preserve rendering of macro_rules matchers when possible)
- #92807 (Update cargo)
- #92832 (Update RELEASES for 1.58.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Swift has specific syntax that desugars to `Option<T>` similar to our
`?` operator, which means that people might try to use it in Rust. Parse
it and gracefully recover.
|
|
|
|
Currently all generators are named with a `generator$N` suffix,
regardless of where they come from. This means an `async fn` shows up as
a generator in stack traces, which can be surprising to async
programmers since they should not need to know that async functions are
implementated using generators.
This change generators a different name depending on the generator kind,
allowing us to tell whether the generator is the result of an async
block, an async closure, an async fn, or a plain generator.
|
|
|
|
|
|
|
|
Closure capture cleanup & refactor
Follow up of #89648
Each commit is self-contained and the rationale/changes are documented in the commit message, so it's advisable to review commit by commit.
The code is significantly cleaner (at least IMO), but that could have some perf implication, so I'd suggest a perf run.
r? `@wesleywiser`
cc `@arora-aman`
|
|
rustdoc: Preserve rendering of macro_rules matchers when possible
Fixes #92331. This approach restores the behavior prior to #86282 **if** the matcher token held by the compiler **and** the matcher token found in the source code are identical TokenTrees. Thus #86208 remains fixed, but without regressing formatting for the vast majority of macros which are not macro-generated.
|
|
[code coverage] Fix missing dead code in modules that are never called
The issue here is that the logic used to determine which CGU to put the dead function stubs in doesn't handle cases where a module is never assigned to a CGU (which is what happens when all of the code in the module is dead).
The partitioning logic also caused issues in #85461 where inline functions were duplicated into multiple CGUs resulting in duplicate symbols.
This commit fixes the issue by removing the complex logic used to assign dead code stubs to CGUs and replaces it with a much simpler model: we pick one CGU to hold all the dead code stubs. We pick a CGU which has exported items which increases the likelihood the linker won't throw away our dead functions and we pick the smallest to minimize the impact on compilation times for crates with very large CGUs.
Fixes #91661
Fixes #86177
Fixes #85718
Fixes #79622
r? ```@tmandry```
cc ```@richkadel```
This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁
|
