| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
syntax: fix dropping of attribute on first param of non-method assocated fn
Fixes #64682.
The general idea is that we bake parsing of `self` into `parse_param_general` and then we just use standard list parsing. Overall, this simplifies the parsing and makes it more consistent.
r? @petrochenkov cc @c410-f3r
|
|
Fuse parsing of `self` into `parse_param_general`.
|
|
|
|
|
|
Rename `*.node` to `*.kind`, and `hair::Pattern*` to `hair::Pat*`
In both `ast::Expr` and `hir::Expr`:
- Rename `Expr.node` to `Expr.kind`.
- Rename `Pat.node` to `Pat.kind`.
- Rename `ImplItem.node` to `ImplItem.kind`.
- Rename `Lit.node` to `Lit.kind`.
- Rename `TraitItem.node` to `TraitItem.kind`.
- Rename `Ty.node` to `Ty.kind`.
- Rename `Stmt.node` to `Stmt.kind`.
- Rename `Item.node` to `Item.kind`.
- Rename `ForeignItem.node` to `ForeignItem.kind`.
- Rename `MetaItem.node` to `MetaItem.kind`.
Also:
- Rename `hair::FieldPattern` to `hair::FieldPat`.
- Rename `hair::PatternKind` to `hair::PatKind`.
- Rename `hair::PatternRange` to `hair::PatRange`.
- Rename `PatternContext` to `PatCtxt`.
- Rename `PatternTypeProjection` to `PatTyProj`.
- Rename `hair::Pattern` to `hair::Pat`.
These two sets of changes are grouped together to aid with merging. The only changes are renamings.
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For both `ast::Expr` and `hir::Expr`.
|
|
Based on issue #64732, when creating a byte literal with single quotes,
the suggestion message would indicate that you meant to write a `str` literal,
but we actually meant to write a byte string literal.
So I changed the unescape_error_reporting.rs to decide whether to print out
"if you meant to write a `str` literal, use double quotes",
or "if you meant to write a byte string literal, use double quotes".
|
|
Then use the diagnostics-stealing API to stash parser
errors and enrich them with type information in typeck.
|
|
Refactor librustc_errors::Handler API
This should be reviewed by-commit.
The last commit moves all fields into an inner struct behind a single lock; this is done to prevent possible deadlocks in a multi-threaded compiler, as well as inconsistent state observation.
|
|
Rollup of 7 pull requests
Successful merges:
- #64294 (Fix `Stdio::piped` example code and lint)
- #64670 (Cleanup syntax::ext::build)
- #64674 (Propagate `types.err` in locals further to avoid spurious knock-down errors)
- #64676 (Parse assoc type bounds in generic params and provide custom diagnostic)
- #64677 (remove outdated comment)
- #64679 (Infer consts more consistently)
- #64688 (Clarify the "since" tidy check)
Failed merges:
r? @ghost
|
|
Parse assoc type bounds in generic params and provide custom diagnostic
Fix #26271.
|
|
|
|
|
|
|
|
|
|
factor out pluralisation remains after #64280
there are two case that doesn't not match the original macro pattern at [here](https://github.com/rust-lang/rust/blob/master/src/librustc_lint/unused.rs#L146) and [here](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/diagnostics.rs#L539) as the provided param is already a bool or the check condition is not `x != 1`, so I change the macro accept a boolean expr instead of number to fit all the cases.
@Centril please review
Fixes #64238.
|
|
Document From trait for LhsExpr in parser
Add doc for From trait for converting P<Expr> and Option<ThinVec<Attribute>> to LhsExpr
As part of issue rust-lang#51430 (cc @skade).
Both of these should just be moving an address and setting a discriminant in an enum. The main thing I'm not sure about is whether it's worth documenting the branch in the From<Option<ThinVec<Attribute>>. As far as I can tell it doesn't seem like it is optimized away (although if the discriminant happened to work out you could just copy the pointer and the discriminant which might be cheaper, but that's not guaranteed). So it seems like if it's being called often, it's doubling the number of possible branch mispredictions on this Option, which could be a significant cost.
Let me know if there's anything that needs fixing and I'll get to it as soon as possible!
|
|
Stabilize `param_attrs` in Rust 1.39.0
# Stabilization proposal
I propose that we stabilize `#![feature(param_attrs)]`.
Tracking issue: #60406
Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable).
## What is stabilized
It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example:
```rust
fn len(
#[cfg(windows)] slice: &[u16],
#[cfg(not(windows))] slice: &[u8],
) -> usize {
slice.len()
}
```
## What isn't stabilized
* Documentation comments like `/// Doc` on parameters.
* Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters.
* Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters.
## Motivation
The chief motivations for stabilizing `param_attrs` include:
* Finer conditional compilation with `#[cfg(..)]` and linting control of variables.
* Richer macro DSLs created by users.
* External tools and compiler internals can take advantage of the additional information that the parameters provide.
For more examples, see the [RFC][rfc motivation].
## Reference guide
In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from:
```rust
FnParam = { pat:Pat ":" }? ty:Type;
VaradicTail = "...";
```
into:
```rust
FnParam = OuterAttr* { pat:Pat ":" }? ty:Type;
VaradicTail = OuterAttr* "...";
```
The grammar of a closure parameter is changed from:
```rust
ClosureParam = pat:Pat { ":" ty:Type }?;
```
into:
```rust
ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?;
```
More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`.
Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros.
## History
* On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position".
* On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made.
* On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril.
* On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk.
* On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed.
* This PR stabilizes `param_attrs`.
## Tests
* [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs)
* [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs)
* [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs)
* [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs)
* [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns.
* [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs)
## Possible future work
* Custom attributes inside function parameters aren't currently supported but it is something being worked on internally.
* Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters.
[rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation
[rfc]: https://github.com/rust-lang/rfcs/pull/2565
[60669]: https://github.com/rust-lang/rust/pull/60669
[61856]: https://github.com/rust-lang/rust/pull/61856
[63210]: https://github.com/rust-lang/rust/issues/63210
[61238]: https://github.com/rust-lang/rust/issues/61238
[63212]: https://github.com/rust-lang/rust/pull/63212
This report is a collaborative work with @Centril.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Box `DiagnosticBuilder`.
It's a large type -- 176 bytes on 64-bit. And it's passed around and
returned from a lot of functions, including within `PResult`.
This commit boxes it, which reduces memory traffic. In particular,
`PResult` shrinks to 16 bytes in the best case; this reduces instruction
counts by up to 2% on various workloads. The commit touches a lot of
lines but it's almost all trivial plumbing changes.
|
|
It's a large type -- 176 bytes on 64-bit. And it's passed around and
returned from a lot of functions, including within PResult.
This commit boxes it, which reduces memory traffic. In particular,
`PResult` shrinks to 16 bytes in the best case; this reduces instruction
counts by up to 2% on various workloads.
|
|
|
|
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
|
|
Aggregation of cosmetic changes made during work on REPL PRs: libsyntax
Factored out from hacking on rustc for work on the REPL.
r? @Centril
|
|
Migrate internal diagnostic registration to macro_rules
Review is best done commit-by-commit.
Fixes #64132.
|
|
|
|
|
