| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 7f6b60899502c45fc0b58adf79d09fb77ffc8884.
|
|
It would be kind of embarrassing to ship with the "issue TBD" message!
|
|
|
|
[beta] back out #53793 - stabilize outlives requirements
Fixes #54467 for beta, looks like a less risky fix than #54701
|
|
|
|
This reverts commit 6810f5286b6b91daab06fc3dccb27d8c46f14349, reversing
changes made to 8586ec6980462c99a8926646201b2444d8938d29.
|
|
|
|
some cases
|
|
|
|
Before this two macros with same name would be indistinguishable inside a
`FileName`. This caused a bug in incremental compilation (see #53097) since
two different macros would map out to the same `StableFilemapId`.
Fixes #53097.
|
|
|
|
editions.
|
|
Rollup of 5 pull requests
Successful merges:
- #53941 (rustdoc: Sort implementors)
- #54181 (Suggest && and || instead of 'and' and 'or')
- #54209 (Partially revert 674a5db "Fix undesirable fallout [from macro modularization]")
- #54213 (De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.)
- #54244 (Add a small search box to seach Rust's standary library)
Failed merges:
r? @ghost
|
|
Partially revert 674a5db "Fix undesirable fallout [from macro modularization]"
Partially revert https://github.com/rust-lang/rust/commit/674a5db1a50e25dd60a8ee6669edee9a366c9fab
~~Closes~~ (see pnkfelix comments below) https://github.com/rust-lang/rust/issues/53675
|
|
Suggest && and || instead of 'and' and 'or'
Resolves #54109.
Note: competing pull reqeust: #54179
r? @csmoe
|
|
use structured suggestion for "missing mut" label
Fixes #54133 for both NLL and non-NLL.
r? @estebank
I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"?
Also, are the `HELP` and `SUGGESTION` comments necessary?
|
|
|
|
|
|
|
|
|
|
resolve: Introduce two sub-namespaces in macro namespace
Two sub-namespaces are introduced in the macro namespace - one for bang macros and one for attribute-like macros (attributes, derives).
"Sub-namespace" means this is not a newly introduced full namespace, the single macro namespace is still in place.
I.e. you still can't define/import two macros with the same name in a single module, `use` imports still import only one name in macro namespace (from any sub-namespace) and not possibly two.
However, when we are searching for a name used in a `!` macro call context (`my_macro!()`) we skip attribute names in scope, and when we are searching for a name used in attribute context (`#[my_macro]`/`#[derive(my_macro)]`) we are skipping bang macro names in scope.
In other words, bang macros cannot shadow attribute macros and vice versa.
For a non-macro analogy, we could e.g. skip non-traits when searching for `MyTrait` in `impl MyTrait for Type { ... }`.
However we do not do it in non-macro namespaces because we don't have practical issues with e.g. non-traits shadowing traits with the same name, but with macros we do, especially after macro modularization.
For `#[test]` and `#[bench]` we have a hack in the compiler right now preventing their shadowing by `macro_rules! test` and similar things. This hack was introduced after making `#[test]`/`#[bench]` built-in macros instead of built-in attributes (https://github.com/rust-lang/rust/pull/53410), something that needed to be done from the start since they are "active" attributes transforming their inputs.
Now they are passed through normal name resolution and can be shadowed, but that's a breaking change, so we have a special hack basically applying this PR for `#[test]` and `#[bench]` only.
Soon all potentially built-in attributes will be passed through normal name resolution (https://github.com/rust-lang/rust/pull/53913) and that uncovers even more cases where the strict "macro namespace is a single namespace" rule needs to be broken.
For example, with strict rules, built-in macro `cfg!(...)` would shadow built-in attribute `#[cfg]` (they are different things), standard library macro `thread_local!(...)` would shadow built-in attribute `#[thread_local]` - both of these cases are covered by special hacks in https://github.com/rust-lang/rust/pull/53913 as well.
Crater run uncovered more cases of attributes being shadowed by user-defined macros (`warn`, `doc`, `main`, even `deprecated`), we cannot add exceptions in the compiler for all of them.
Regressions with user-defined attributes like https://github.com/rust-lang/rust/issues/53583 and https://github.com/rust-lang/rust/issues/53898 also appeared after enabling macro modularization.
People are also usually confused (https://github.com/rust-lang/rust/issues/53205#issuecomment-411552763, https://github.com/rust-lang/rust/issues/53583#issuecomment-415447800) when they see conflicts between attributes and non-attribute macros for the first time.
So my proposed solution is to solve this issue by introducing two sub-namespaces and thus skipping resolutions of the wrong kind and preventing more error-causing cases of shadowing.
Fixes https://github.com/rust-lang/rust/issues/53583
|
|
rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's.
In particular, this allows this pattern that @cramertj mentioned in https://github.com/rust-lang/rust/issues/53130#issuecomment-420848814:
```rust
use log::{debug, log};
fn main() {
use log::{debug, log};
debug!(...);
}
```
The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`.
Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes).
With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice).
This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011.
Only the last commit is the main change, the other two are cleanups.
r? @petrochenkov cc @Centril @joshtriplett
|
|
[NLL] Suggest let binding
Closes #49821
Also adds an alternative to `explain_why_borrow_contains_point` that allows changing error messages based on the reason that will be given. This will also be useful for #51026, #51169 and maybe further changes to does not live long enough messages.
|
|
Addressed #53692
@sunjay @estebank @csmoe hopefully this answer #53692
Please let me know if you have any suggestion
|
|
Add forever unstable attribute to allow specifying arbitrary scalar ranges
r? @eddyb for the first commit and @nikomatsakis for the second one
|
|
Suggest valid crate type if invalid crate type is found
This adds a suggestion to the `invalid_crate_types` lint.
The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.
Closes #53958
|
|
Implement RFC 2302: tuple_struct_self_ctor
Tracking issue: https://github.com/rust-lang/rust/issues/51994
|
|
|
|
resolve to distinct Def's.
|
|
This adds a suggestion to the `invalid_crate_types` lint.
The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.
|
|
|
|
Advised by @estebank.
|
|
Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
|
|
Add a test that tries to modify static memory at compile-time
Attempt to fix #53818
cc @oli-obk
|
|
|
|
|
|
|
|
|
|
Do not emit E0277 on incorrect tuple destructured binding
Fix #50333.
|
|
Fixes #54133.
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
|
|
Recover proper regression test for issue #16278.
Spawned from my note https://github.com/rust-lang/rust/pull/19955#issuecomment-420430761
|
|
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
|
|
|
|
|
|
nikomatsakis:nll-universe-subtyping-and-pattern-ascription, r=pnkfelix
support ascription for patterns in NLL
This implements the strategy outlined in [this comment](https://github.com/rust-lang/rust/issues/47184#issuecomment-416669986):
- We first extend the NLL subtyping code so it can handle inference variables and subtyping.
- Then we extend HAIR patterns with type ascription.
- Then we treat the type `T` in `let pat: T = ...` as an ascription.
Before landing, a few things:
- [x] Fix the WF rule bug (filed a FIXME https://github.com/rust-lang/rust/issues/54105)
- [x] Fix an ICE I encountered locally around bound regions, or else file a follow-up
- [x] More tests probably =)
r? @pnkfelix
|
|
r=alexcrichton
warn about keywords in macro invocations
Fixes #53686
r? @alexcrichton
|
|
Co-authored-by: nikomatsakis
|
|
|
