| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
stability: More precise location for deprecation lint on macros
One missing piece of https://github.com/rust-lang/rust/pull/73178.
|
|
rustc_resolve: Make `macro_rules` scope chain compression lazy
As suggested in https://github.com/rust-lang/rust/pull/78826#issuecomment-723420664.
|
|
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name
Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350.
See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627.
The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088).
## User-facing changes
- `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this.
- Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway.
- `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`.
- `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`.
## Implementation changes
The main change is that `UnstableOptions::from_environment` now requires
an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how.
Other major changes:
- Added `Session::is_nightly_build()`, which uses the `crate_name` of
the session
- Added `nightly_options::match_is_nightly_build`, a convenience method
for looking up `--crate-name` from CLI arguments.
`Session::is_nightly_build()`should be preferred where possible, since
it will take into account `#![crate_name]` (I think).
- Added `unstable_features` to `rustdoc::RenderOptions`
I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too.
r? `@joshtriplett`
cc `@Mark-Simulacrum` `@hsivonen`
|
|
|
|
resolve: Collapse `macro_rules` scope chains on the fly
Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports.
Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815
|
|
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
rustc_resolve: Use `#![feature(format_args_capture)]`
This is the best new sugar for quite some time.
(I only changed places that already used named arguments.)
|
|
|
|
The main change is that `UnstableOptions::from_environment` now requires
an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how.
Other major changes:
- Added `Session::is_nightly_build()`, which uses the `crate_name` of
the session
- Added `nightly_options::match_is_nightly_build`, a convenience method
for looking up `--crate-name` from CLI arguments.
`Session::is_nightly_build()`should be preferred where possible, since
it will take into account `#![crate_name]` (I think).
- Added `unstable_features` to `rustdoc::RenderOptions`
There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no
longer active nightly features. In practice this shouldn't be a big
deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone
uses `RUSTC_BOOTSTRAP=1` anyway.
- Add tests
Check against `Cheat`, not whether nightly features are allowed.
Nightly features are always allowed on the nightly channel.
- Only call `is_nightly_build()` once within a function
- Use booleans consistently for rustc_incremental
Sessions can't be passed through threads, so `read_file` couldn't take a
session. To be consistent, also take a boolean in `write_file_header`.
|
|
|
|
more case""
This reverts commit b20bce8ce54ea9d47c2e3eb0b17cbb6baf916ae2.
It retains the test added in that commit as a check-pass test, intended to
prevent future (unintentional) regressions.
|
|
filter_next
manual_strip
redundant_static_lifetimes
single_char_pattern
unnecessary_cast
unused_unit
op_ref
redundant_closure
useless_conversion
|
|
|
|
Suggest calling associated `fn` inside `trait`s
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
|
|
|
|
|
|
[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path
This improves the performance of the `resolve_crate` function by 30% for
a very large single file crate with auto-generated C bindings.
cc `@rylev`
|
|
min_const_generics: allow ty param in repeat expr
implements https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/repeat.20expressions
Even with `min_const_generics` active, now keeps resulting in future compat warnings instead of hard errors.
Const parameters, for example `[0; N + 1]`, still result in hard errors during resolve.
```rust
#![allow(dead_code)]
fn foo<T>() {
[0; std::mem::size_of::<*mut T>()];
}
struct Foo<T>(T);
impl<T> Foo<T> {
const ASSOC: usize = 4;
fn test() {
[0; Self::ASSOC];
}
}
```
r? @varkor cc @petrochenkov
|
|
This improves the performance of the `resolve_crate` function by 30% for
a very large single file crate with auto-generated C bindings.
|
|
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
|
|
This commit improves the diagnostic emitted when a tuple struct is being
constructed which has private fields so that private fields are
labelled and the message is improved.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Compute proper module parent during resolution
Fixes #75982
The direct parent of a module may not be a module
(e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`).
To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.
|
|
fix def collector for impl trait
fixes #77329
We now consistently make `impl Trait` a hir owner, requiring some special casing for synthetic generic params.
r? `@eddyb`
|
|
Fixes #75982
The direct parent of a module may not be a module
(e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`).
To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.
|
|
|
|
|
|
Use `DroplessArena` where we know the type doesn't need drop
This PR uses a single `DroplessArena` in resolve instead of three separate `TypedArena`s.
`DroplessArena` checks that the type indeed doesn't need drop, so in case the types change, this will result in visible failures.
|
|
|
|
Then use them through a query based on resolver outputs
|
|
Suggest correct place to add `self` parameter when inside closure
It would incorrectly suggest adding it as a parameter to the closure instead of the containing function.
[For example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1936bcd1e5f981573386e0cee985c3c0):
```
help: add a `self` receiver parameter to make the associated `fn` a method
|
5 | let _ = || self&self;
| ^^^^^
```
`DiagnosticMetadata.current_function` is only used for these messages so tweaking its behavior should be ok.
|
|
It would incorrectly suggest adding it as a parameter to the closure instead of the
containing function.
|
|
|
|
davidtwco:pr-77341-follow-up-non-constructable-variants, r=estebank
resolve: further improvements to "try using the enum's variant" diagnostic
Follow-up on https://github.com/rust-lang/rust/pull/77341#issuecomment-702738281.
This PR improves the diagnostic modified in #77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly.
I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like `..` in those spans, which doesn't seem worth it).
r? @estebank
|
|
Suggest imports of unresolved macros
Closes https://github.com/rust-lang/rust/issues/75191.
|
|
This commit improves the tuple struct case added in rust-lang/rust#77341
so that the context is mentioned in more of the message.
Signed-off-by: David Wood <david@davidtw.co>
|
|
This commit improves the diagnostic modified in rust-lang/rust#77341 to
suggest not only those variants which do not have fields, but those with
fields (by suggesting with placeholders).
Signed-off-by: David Wood <david@davidtw.co>
|
|
`min_const_generics` diagnostics improvements
As disscussed in [zulip/project-const-generics/non-trivial anonymous constant](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/non-trivial.20anonymous.20constants).
This is my first PR on the compiler.
@lcnr is mentoring me on this PR.
Related to #60551.
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
2
3
|
|
|
|
|
|
Fix #75829
|
|
|
