| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
rustc_session: default to -Z plt=yes on non-x86_64
Per the discussion in #106380 plt=no isn't a great default, and rust-lang/compiler-team#581 decided that the default should be PLT=yes for everything except x86_64. Not everyone agrees about the x86_64 part of this change, but this at least is an improvement in the state of things without changing the x86_64 situation, so I've attempted making this change in the name of not letting the perfect be the enemy of the good.
Please let me know if I've messed this up somehow - I'm not wholly confident I got this right.
r? `@nikic`
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #111747 (Don't structurally resolve during method ambiguity in probe)
- #112704 (slice::from_raw_parts: mention no-wrap-around condition)
- #112927 (Fix indentation for where clause in rustdoc pages)
- #112933 (Avoid `&format` in error message code)
- #112935 (style-guide: Fix typo)
- #112941 (typo)
- #112942 (style-guide: Organizational and editing tweaks (no semantic changes))
- #112944 (style-guide: Add language disclaiming any effects on non-default Rust styles)
- #112948 (Avoid guessing unknown trait implementation in suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Avoid guessing unknown trait implementation in suggestions
When a trait is used without specifying the implementation (e.g. calling a non-member associated function without fully-qualified syntax) and there are multiple implementations available, use a placeholder comment for the implementation type in the suggestion instead of picking a random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Fixes #112897
|
|
joshtriplett:style-guide-defaults-vs-configurability, r=compiler-errors
style-guide: Add language disclaiming any effects on non-default Rust styles
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
Otherwise, people might wonder (for instance) if there's a semantic difference
between "must" and "should" in the style guide, and whether tools are "allowed"
to offer configurability of something that says "must".
|
|
style-guide: Organizational and editing tweaks (no semantic changes)
I'd recommend reviewing this PR commit-by-commit; each commit is self-contained
and should be easy to review at a glance.
- style-guide: Move text about block vs visual indent to indentation section
- style-guide: Move and expand text about trailing commas
- style-guide: s/right-ward/rightward/
- style-guide: Consistently refer to rustfmt as `rustfmt`
- style-guide: Remove inaccurate statement about rustfmt
- style-guide: Define (and capitalize) "ASCIIbetically"
- style-guide: Update cargo.md for authors being optional and not recommended
- style-guide: Avoid normative recommendations for formatting tool configurability
- style-guide: Clarify advice on names matching keywords
- style-guide: Reword an awkwardly phrased recommendation (and fix a typo)
- style-guide: Rephrase a confusingly ordered, ambiguous sentence (and fix a typo)
- style-guide: Avoid hyphenating "semicolon"
- style-guide: Make link text in SUMMARY.md match the headings in the linked pages
- style-guide: Define what an item is
- style-guide: Avoid referring to the style team in the past tense
|
|
typo
|
|
style-guide: Fix typo
"does done fit" should have been "does not fit".
|
|
Avoid `&format` in error message code
follow-up of #111633
|
|
Fix indentation for where clause in rustdoc pages
Screenshot of the bug:
I used this opportunity to clarify the code a bit because some weird things were going on.
r? ````@notriddle````
|
|
slice::from_raw_parts: mention no-wrap-around condition
Cc https://github.com/rust-lang/rust/issues/83996. This probably needs to be mentioned in more places, so I am not closing that issue, but this here should help at least.
|
|
r=fee1-dead
Don't structurally resolve during method ambiguity in probe
See comment in UI test for reason for the failure. This is all on the error path anyways, not really sure what the assertion is there to achieve anyways...
Fixes #111739
|
|
Codegen cleanups
Some cleanups I found while looking closely at this code.
r? `@tmiasko`
|
|
When a trait is used without specifying the implementation (e.g. calling
a non-member associated function without fully-qualified syntax) and
there are multiple implementations available, use a placeholder comment
for the implementation type in the suggestion instead of picking a
random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
|
|
|
|
|
|
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
|
|
We live!
|
|
|
|
|
|
|
|
This sentence had a parenthetical without a closing parenthesis, and had
the phrase "which doesn't require special formatting" ambiguously at the
end of a list when it only applied to the last item of the list.
|
|
|
|
|
|
In particular, specify what this advice is an alternative to (creative
misspellings such as `krate`).
|
|
It's not within the scope of the style guide to tell formatting tools
whether, or how, to allow configurability of non-default formatting.
|
|
Change an example using the authors field to use a long feature list instead.
Change the conventions for the authors field to say "if present".
|
|
The style guide didn't give any definition for it.
|
|
rustfmt does include a mechanism to distinguish standard library
imports, which it does syntactically by crate name. Avoid making a
misleading statement that implies it cannot do this.
|
|
|
|
We already use the word "rightward" elsewhere; avoid the unnecessarily
hyphenated "right-ward".
|
|
`principles.md` includes some high-level guiding principles for
formatting, but also includes a few specific formatting provisions.
While those provisions apply in many places, the same holds true for
other high-level guidance. Move the text about trailing commas to
`README.md`, so that `principles.md` can focus on guiding principles
while the top level of the style guide gives concrete formatting
recommendations.
|
|
`principles.md` includes some high-level guiding principles for
formatting, but also includes a few specific formatting provisions.
While those provisions apply in many places, the same holds true for
other high-level guidance, such as the indentation section. Move the
text about using block indent rather than visual indent to the
indentation section, so that `principles.md` can focus on guiding
principles while the top level of the style guide gives concrete
formatting recommendations.
|
|
"does done fit" should have been "does not fit".
|
|
|
|
Per the discussion in #106380 plt=no isn't a great default, and
rust-lang/compiler-team#581 decided that the default should be PLT=yes
for everything except x86_64. Not everyone agrees about the x86_64 part
of this change, but this at least is an improvement in the state of
things without changing the x86_64 situation, so I've attempted making
this change in the name of not letting the perfect be the enemy of the
good.
|
|
Account for sealed traits in privacy and trait bound errors
On trait bound errors caused by super-traits, identify if the super-trait is publicly accessibly and if not, explain "sealed traits".
```
error[E0277]: the trait bound `S: Hidden` is not satisfied
--> $DIR/sealed-trait-local.rs:17:20
|
LL | impl a::Sealed for S {}
| ^ the trait `Hidden` is not implemented for `S`
|
note: required by a bound in `Sealed`
--> $DIR/sealed-trait-local.rs:3:23
|
LL | pub trait Sealed: self::b::Hidden {
| ^^^^^^^^^^^^^^^ required by this bound in `Sealed`
= note: `Sealed` is a "sealed trait", because to implement it you also need to implelement `a::b::Hidden`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it
```
Deduplicate privacy errors that point to the same path segment even if their deduplication span are different.
When encountering a path that is not reachable due to privacy constraints path segments other than the last, keep metadata for the last path segment's `Res` in order to look for alternative import paths for that item to suggest. If there are none, be explicit that the item is not accessible.
```
error[E0603]: module `b` is private
--> $DIR/re-exported-trait.rs:11:9
|
LL | impl a::b::Trait for S {}
| ^ private module
|
note: the module `b` is defined here
--> $DIR/re-exported-trait.rs:5:5
|
LL | mod b {
| ^^^^^
help: consider importing this trait through its public re-export instead
|
LL | impl a::Trait for S {}
| ~~~~~~~~
```
```
error[E0603]: module `b` is private
--> $DIR/private-trait.rs:8:9
|
LL | impl a::b::Hidden for S {}
| ^ ------ trait `b` is not publicly reachable
| |
| private module
|
note: the module `b` is defined here
--> $DIR/private-trait.rs:2:5
|
LL | mod b {
| ^^^^^
```
|
|
|
|
Suggest publicly accessible paths for items in private mod:
When encountering a path in non-import situations that are not reachable
due to privacy constraints, search for any public re-exports that the
user could use instead.
Track whether an import suggestion is offering a re-export.
When encountering a path with private segments, mention if the item at
the final path segment is not publicly accessible at all.
Add item visibility metadata to privacy errors from imports:
On unreachable imports, record the item that was being imported in order
to suggest publicly available re-exports or to be explicit that the item
is not available publicly from any path.
In order to allow this, we add a mode to `resolve_path` that will not
add new privacy errors, nor return early if it encounters one. This way
we can get the `Res` corresponding to the final item in the import,
which is used in the privacy error machinery.
|
|
When implementing a public trait with a private super-trait, we now emit
a note that the missing bound is not going to be able to be satisfied,
and we explain the concept of a sealed trait.
|
|
|
|
|
|
r=compiler-errors
Avoid `Lrc<Box<dyn CodegenBackend>>`.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and `Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc, and (b) Clippy knew about `Lrc`.)
r? `@bjorn3`
|
|
Inline before merging cgus
Because CGU merging relies on CGU sizes, but the CGU sizes before inlining aren't accurate.
This change doesn't have much effect on compile perf, but it makes follow-on changes that involve more sophisticated reasoning about CGU sizes much easier.
r? `@wesleywiser`
|
|
Rollup of 4 pull requests
Successful merges:
- #112876 (Don't substitute a GAT that has mismatched generics in `OpaqueTypeCollector`)
- #112906 (rustdoc: render the body of associated types before the where-clause)
- #112907 (Update cargo)
- #112908 (Print def_id on EarlyBoundRegion debug)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=compiler-errors
Print def_id on EarlyBoundRegion debug
It's not the first time that I can't make sense out of the default debug print on `EarlyBoundRegion`. As I was working on #112682 I needed this.
I was doing some git archeology and found that we used to print everything https://github.com/spastorino/rust/blob/dfbc9608ce5c9655a36b63f6cc9694f5e4ad9890/src/librustc/util/ppaux.rs#L425-L430 but we lost the ability in some refactor midway.
|
|
Update cargo
2 commits in dead4b8740c4b6a8ed5211e37c99cf81d01c3b1c..4cebd130ebca3bc219180a54f3e26cc1b14a91de
2023-06-20 20:07:17 +0000 to 2023-06-21 18:59:29 +0000
- fix: Allow embedded manifests in all commands (rust-lang/cargo#12289)
- feat(cli): Support `cargo Cargo.toml` (rust-lang/cargo#12281)
r? `@ghost`
|
|
fmease:rustdoc-render-assoc-ty-body-before-where-clause, r=notriddle
rustdoc: render the body of associated types before the where-clause
Fixes #112903.
|
