| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
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.
|
|
resolve: Future proof resolutions for potentially built-in attributes
This is not full "pass all attributes through name resolution", but a more conservative solution.
If built-in attribute is ambiguous with any other macro in scope, then an error is reported.
What complications arise with the full solution - https://github.com/rust-lang/rust/pull/53913#issuecomment-418204136.
cc https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
cc https://github.com/rust-lang/rust/issues/52269
Closes https://github.com/rust-lang/rust/issues/53531
|
|
Co-authored-by: nikomatsakis
|
|
stabilize #[used]
closes #40289
RFC for stabilization: rust-lang/rfcs#2386
r? @Centril
Where should this be documented? Currently the documentation is in the unstable book
|
|
Don't compute padding of braces unless they are unmatched
Follow up to #53949. Attempt to fix # #54083.
r? @nikomatsakis
|
|
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
|
|
Feature gate non-builtin attributes in inner attribute position
Closes item 3 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
|
|
|
|
|
|
|
|
|
|
resolve: Relax shadowing restrictions on macro-expanded macros
Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes.
Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros.
See comments to `fn may_appear_after` and added tests for more details and examples.
The functional changes are a21f6f588fc28c97533130ae44a6957b579ab58c and 46dd365ce9ca0a6b8653849b80267763c542842a, other commits are refactorings.
|
|
r=Mark-Simulacrum
Stabilize edition 2018; also updates Clippy, RLS and Cargo
Supersedes https://github.com/rust-lang/rust/pull/53999 , https://github.com/rust-lang/rust/pull/53935
Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it.
The clippy update enables the corresponding feature explicitly.
r? @Mark-Simulacrum
|
|
closes #40289
|
|
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
```rust
mod m {
type T =
}
```
```console
error: expected type, found `}`
--> src/main.rs:3:1
|
3 | }
| ^
```
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
|
|
|
|
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.
|
|
|
|
Improve messages for un-closed delimiter errors
|
|
|
|
Whitelist `#[rustc_transparent_macro]` so it's not interpreted as a potential attribute macro
|
|
stabilize #[panic_handler]
closes #44489
### Update(2018-09-07)
This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946
Documentation PRs:
- Reference. https://github.com/rust-lang-nursery/reference/pull/362
- Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75
---
`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.
(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054
Some unresolved questions from #44489:
> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".
The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.
> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?
I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?
---
Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.
cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
|
|
|
|
|
|
|
|
* When encountering EOF, point at the last opening brace that does not
have the same indentation level as its close delimiter.
* When encountering the wrong type of close delimiter, point at the
likely correct open delimiter to give a better idea of what went
wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
|
|
Rollup of 9 pull requests
Successful merges:
- #53076 (set cfg(rustdoc) when rustdoc is running on a crate)
- #53622 (cleanup: Add main functions to some UI tests)
- #53769 (Also link Clippy repo in the CONTRIBUTING.md file)
- #53774 (Add rust-gdbgui script.)
- #53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any"))
- #53782 (Make Arc cloning mechanics clearer in module docs)
- #53790 (Add regression test for issue #52060)
- #53801 (Prevent duplicated impl on foreign types)
- #53850 (Nuke the `const_to_allocation` query)
|
|
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
|
|
|
|
|
|
r=cramertj
Fix stabilisation version for macro_vis_matcher.
r? @cramertj
|
|
set applicability
Update a few more calls as described in #50723
r? @estebank
|
|
Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.
Most of the compiler uses the `Fx` hasher but some places ended up with the default one.
|
|
|
|
|
|
|
|
|
|
fix for late-bound regions
Fix for https://github.com/rust-lang/rust/issues/53419
r? @nikomatsakis
|
|
|
|
add #[panic_handler]; deprecate #[panic_implementation]
r? @SimonSapin
cc #44489
|
|
Remove anonymous trait params from 2018 and beyond
cc @Centril @nikomatsakis
cc #41686 rust-lang/rfcs#2522 #53272
This PR removes support for anonymous trait parameters syntactically in rust 2018 and onward.
TODO:
- [x] Add tests
|
