| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
|
|
This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
|
|
Rollup of 9 pull requests
Successful merges:
- #104363 (Make `unused_allocation` lint against `Box::new` too)
- #106633 (Stabilize `nonzero_min_max`)
- #106844 (allow negative numeric literals in `concat!`)
- #108071 (Implement goal caching with the new solver)
- #108542 (Force parentheses around `match` expression in binary expression)
- #108690 (Place size limits on query keys and values)
- #108708 (Prevent overflow through Arc::downgrade)
- #108739 (Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time)
- #108806 (Querify register_tools and post-expansion early lints)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Querify register_tools and post-expansion early lints
The 2 extra queries correspond to code that happen before and after macro expansion, and don't need the resolver to exist.
|
|
This is a regression from #94857.
|
|
|
|
|
|
|
|
rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
|
|
|
|
|
|
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
|
|
r=GuillaumeGomez
rustdoc: reduce allocations when generating tooltips
An attempt to reduce the perf regression in
https://github.com/rust-lang/rust/pull/108052#issuecomment-1430631861
|
|
r=compiler-errors
diagnostics: avoid querying `associated_item` in the resolver
Fixes #108529
CC #108324
|
|
Move the unused extern crate check back to the resolver.
It doesn't have anything to do in `rustc_hir_typeck`.
|
|
Fixes #108529
|
|
|
|
An attempt to reduce the perf regression in
https://github.com/rust-lang/rust/pull/108052#issuecomment-1430631861
|
|
r=compiler-errors,davidtwco,estebank,oli-obk
diagnostics: if AssocFn has self argument, describe as method
Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515
This commit also changes the tooltips on rustdoc intra-doc links targeting methods.
For anyone not sure why this is being done, see the Reference definitions of these terms in <https://doc.rust-lang.org/1.67.1/reference/items/associated-items.html#methods>
> Associated functions whose first parameter is named `self` are called methods and may be invoked using the [method call operator](https://doc.rust-lang.org/1.67.1/reference/expressions/method-call-expr.html), for example, `x.foo()`, as well as the usual function call notation.
In particular, while this means it's technically correct for rustc to refer to a method as an associated function (and there are a few cases where it'll still do so), rustc *must never* use the term "method" to refer to an associated function that does not have a `self` parameter.
|
|
|
|
|
|
resolve: Remove `ImportResolver`
It's a trivial wrapper over `Resolver` that doesn't bring any benefits
|
|
It's a trivial wrapper over `Resolver` that doesn't bring any benefits
|
|
Discussed in
https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515
This commit also changes the tooltips on rustdoc intra-doc links
targeting methods.
|
|
errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter.
There are advantages and disadvantages to this change..
#### Advantages
- Changing a diagnostic now only recompiles the crate for that diagnostic and those crates that depend on it, rather than `rustc_error_messages` and all crates thereafter.
- This approach can be used to support first-party crates that want to supply translatable diagnostics (e.g. `rust-lang/thorin` in https://github.com/rust-lang/rust/pull/102612#discussion_r985372582, cc `@JhonnyBillM)`
- We can extend this a little so that tools built using rustc internals (like clippy or rustdoc) can add their own diagnostic resources (much more easily than those resources needing to be available to `rustc_error_messages`)
#### Disadvantages
- Crates can only refer to the diagnostic messages defined in the current crate (or those from dependencies), rather than all diagnostic messages.
- `rustc_driver` (or some other crate we create for this purpose) has to directly depend on *everything* that has error messages.
- It already transitively depended on all these crates.
#### Pending work
- [x] I don't know how to make `rustc_codegen_gcc`'s translated diagnostics work with this approach - because `rustc_driver` can't depend on that crate and so can't get its resources to provide to the diagnostic emission. I don't really know how the alternative codegen backends are actually wired up to the compiler at all.
- [x] Update `triagebot.toml` to track the moved FTL files.
r? `@compiler-errors`
cc #100717
|
|
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
|
|
give the resolver access to TyCtxt
The resolver is now created after TyCtxt is created. Then macro expansion and name resolution are run and the results fed into queries just like before this PR.
Since the resolver had (before this PR) mutable access to the `CStore` and the source span table, these two datastructures are now behind a `RwLock`. To ensure that these are not mutated anymore after the resolver is done, a read lock to them is leaked right after the resolver finishes.
### PRs split out of this one and leading up to it:
* https://github.com/rust-lang/rust/pull/105423
* https://github.com/rust-lang/rust/pull/105357
* https://github.com/rust-lang/rust/pull/105603
* https://github.com/rust-lang/rust/pull/106776
* https://github.com/rust-lang/rust/pull/106810
* https://github.com/rust-lang/rust/pull/106812
* https://github.com/rust-lang/rust/pull/108032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
when using TyCtxt
|
|
using TyCtxt
|
|
remove FIXME that doesn't require fixing
|
|
r=tmiasko
Use restricted Damerau-Levenshtein distance for diagnostics
This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement.
~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~
r? ``@estebank``
``@rustbot`` label +A-diagnostics +C-enhancement
|
|
|
|
|
|
|
|
GuillaumeGomez:correctly-handle-links-starting-with-whitespace, r=petrochenkov
Correctly handle links starting with whitespace
Part of https://github.com/rust-lang/rust/issues/107995.
I just got this issue, wrote a fix and then saw the issue. So here's the PR. ^^'
r? `@petrochenkov`
|
|
resolve: Fix doc links referring to other crates when documenting proc macro crates directly
Fixes https://github.com/rust-lang/rust/issues/107950
|