about summary refs log tree commit diff
path: root/src/libsyntax
AgeCommit message (Collapse)AuthorLines
2019-01-22Rollup merge of #57798 - hellow554:master, r=davidtwcoMazdak Farrokhzad-12/+12
Corrected spelling inconsistency resolves #57773
2019-01-22Rollup merge of #57667 - ishitatsuyuki:p-leak, r=nnethercoteMazdak Farrokhzad-0/+1
Fix memory leak in P::filter_map Probably this function isn't widely used, but anyway this wasn't working as intended. r? @eddyb Do not rollup if you want to see if max-rss change in perf.
2019-01-22Corrected spelling inconsistencyMarcel Hellwig-12/+12
resolves #57773
2019-01-21Accept more invalid code that is close to correct fieldsEsteban Küber-2/+20
2019-01-22Extend trailing `>` detection for paths.David Wood-33/+61
This commit extends the trailing `>` detection to also work for paths such as `Foo::<Bar>>:Baz`. This involves making the existing check take the token that is expected to follow the path being checked as a parameter. Care is taken to ensure that this only happens on the construction of a whole path segment and not a partial path segment (during recursion). Through this enhancement, it was also observed that the ordering of right shift token and greater than tokens was overfitted to the examples being tested. In practice, given a sequence of `>` characters: `>>>>>>>>>` ..then they will be split into `>>` eagerly: `>> >> >> >> >`. ..but when a `<` is prepended, then the first `>>` is split: `<T> > >> >> >> >` ..and then when another `<` is prepended, a right shift is first again: `Vec<<T>> >> >> >> >` In the previous commits, a example that had two `<<` characters was always used and therefore it was incorrectly assumed that `>>` would always be first - but when there is a single `<`, this is not the case.
2019-01-21Pluralize error messages.David Wood-2/+9
This commit pluralizes error messages when more than a single trailing `>` character is present.
2019-01-21Add error for trailing angle brackets.David Wood-0/+111
This commit adds a error (and accompanying machine applicable suggestion) for trailing angle brackets on function calls with a turbofish.
2019-01-20Use structured suggestion in stead of notesEsteban Küber-3/+10
2019-01-21Rollup merge of #57784 - JohnTitor:improve-error-message, r=estebankMazdak Farrokhzad-4/+8
Add span for bad doc comment Fixes #57382 r? @estebank
2019-01-21Rollup merge of #57768 - estebank:type-args-sugg, r=zackmdavisMazdak Farrokhzad-1/+11
Continue parsing after parent type args and suggest using angle brackets ``` error[E0214]: parenthesized parameters may only be used with a trait --> $DIR/E0214.rs:2:15 | LL | let v: Vec(&str) = vec!["foo"]; | ^^^^^^ | | | only traits may use parentheses | help: use angle brackets instead: `<&str>` ``` r? @zackmdavis
2019-01-20Tweak field parse error recoveryEsteban Küber-19/+6
2019-01-20Extend incorrect float literal recovery to account for suffixesEsteban Küber-4/+16
2019-01-20Reword message for incorrect float literalEsteban Küber-2/+2
2019-01-21Add span for bad doc commentYuki Okushi-4/+8
2019-01-20Auto merge of #56884 - euclio:codeblock-diagnostics, r=QuietMisdreavusbors-13/+0
rustdoc: overhaul code block lexing errors Fixes #53919. This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level. Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future. Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly. Of note: - The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is. - `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review. - This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
2019-01-20Recover with suggestion from writing `.42` instead of `0.42`Esteban Küber-0/+26
2019-01-20Recover from parse errors in struct literal fieldsEsteban Küber-8/+39
Attempt to recover from parse errors while parsing a struct's literal fields by skipping tokens until a comma or the closing brace is found. This allows errors in other fields to be reported.
2019-01-20Auto merge of #57651 - JohnTitor:give-char-type, r=estebankbors-6/+23
Implement new literal type `Err` Fixes #57384 I removed `return Ok`, otherwise, two errors occur. Any solutions? r? @estebank
2019-01-20Revert changeYuki Okushi-3/+2
2019-01-20Mark incorrect recovered `char` literals as `TyErr` to avoid type errorsYuki Okushi-3/+14
2019-01-19Suggest usage of angle bracketsEsteban Küber-1/+1
2019-01-19Accept parenthesized type args for error recoveryEsteban Küber-0/+10
2019-01-20[WIP] Improve error behaviorYuki Okushi-6/+8
2019-01-19Rollup merge of #57699 - euclio:applicability-ify, r=petrochenkovMazdak Farrokhzad-2/+7
add applicability to remaining suggestions Fixes #50723. I noticed that the suggestion methods on `DiagnosticBuilder` weren't actually deprecated due to #57679. This PR deprecates them properly and fixes the remaining usages. There's also a PR for clippy at rust-lang/rust-clippy#3667.
2019-01-19Rollup merge of #57486 - nnethercote:simplify-TokenStream-more, r=petrochenkovMazdak Farrokhzad-166/+76
Simplify `TokenStream` some more These commits simplify `TokenStream`, remove `ThinTokenStream`, and avoid some clones. The end result is simpler code and a slight perf win on some benchmarks. r? @petrochenkov
2019-01-19Rollup merge of #57610 - mark-i-m:nested-matchers, r=petrochenkovMazdak Farrokhzad-4/+10
Fix nested `?` matchers fix #57597 I'm not 100% if this works yet... cc @alercah When this is ready (but perhaps not yet):
2019-01-18Rollup merge of #57720 - dlrobertson:fix_57521, r=estebankMazdak Farrokhzad-15/+6
Fix suggestions given mulitple bad lifetimes When given multiple lifetimes prior to type parameters in generic parameters, do not ICE and print the correct suggestion. r? @estebank CC @pnkfelix Fixes: #57521
2019-01-18Fix suggestions given mulitple bad lifetimesDan Robertson-15/+6
When given multiple lifetimes prior to type parameters in generic parameters, do not ICE and print the correct suggestion.
2019-01-18Change from mk_lit! to cx.exprYuki Okushi-1/+1
2019-01-18Continue chekingYuki Okushi-1/+1
2019-01-18Change from error to invalidYuki Okushi-1/+1
2019-01-17properly deprecate suggestion methodsAndy Russell-2/+7
2019-01-17Auto merge of #57520 - alexreg:tidy-copyright-lint, r=Mark-Simulacrumbors-1/+1
Add lint for copyright headers to 'tidy' tool r? @Mark-Simulacrum CC @centril
2019-01-16Auto merge of #57321 - petrochenkov:atokens, r=nikomatsakisbors-179/+281
Implement basic input validation for built-in attributes Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax"). For some subset of attributes (found by crater run), errors are lowered to deprecation warnings. NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
2019-01-16Fix memory leak in P::filter_mapTatsuyuki Ishi-0/+1
2019-01-16Cancel processYuki Okushi-1/+1
2019-01-16Add new literal type ErrYuki Okushi-0/+5
2019-01-15fix nested matchers with ?mark-4/+10
2019-01-15Rollup merge of #57467 - JohnTitor:implement-the-check-attribute-1, r=oli-obkMazdak Farrokhzad-2/+2
Implement `check_attribute` to forbid `#[allow_internal_unsafe]` Fixes #56768. r? @oli-obk
2019-01-14stabilize extern_crate_selfRyan Leckey-3/+2
2019-01-14rustdoc: check code block syntax in early passAndy Russell-13/+0
2019-01-15Add PartialEqYuki Okushi-2/+2
2019-01-14Rollup merge of #57585 - estebank:trailing-semicolon, r=petrochenkovMazdak Farrokhzad-24/+35
Recover from item trailing semicolon CC https://github.com/rust-lang/rfcs/pull/2479 r? @petrochenkov
2019-01-14Rollup merge of #57572 - Centril:unaccept-extern-in-path, r=petrochenkovMazdak Farrokhzad-34/+8
Unaccept `extern_in_paths` Based on completed fcp-close in https://github.com/rust-lang/rust/issues/55600, this removes `extern_in_path` (e.g. `extern::foo::bar`) from the language. The changes are primarily reversing https://github.com/rust-lang/rust/commit/32db83b16e06cb5cca72d0e6a648a8008eda0fac. Closes https://github.com/rust-lang/rust/issues/55600 r? @petrochenkov
2019-01-14Rollup merge of #57540 - estebank:eval-more, r=petrochenkovMazdak Farrokhzad-31/+122
Modify some parser diagnostics to continue evaluating beyond the parser Continue evaluating further errors after parser errors on: - trailing type argument attribute - lifetime in incorrect location - incorrect binary literal - missing `for` in `impl Trait for Foo` - type argument in `where` clause - incorrect float literal - incorrect `..` in pattern - associated types - incorrect discriminator value variant error and others. All of these were found by making `continue-parse-after-error` `true` by default to identify errors that would need few changes. There are now only a handful of errors that have any change with `continue-parse-after-error` enabled. These changes make it so `rust` _won't_ stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors. Each commit has an individual diagnostic change with their corresponding tests. CC #48724.
2019-01-14Rollup merge of #57465 - jethrogb:jb/stablize-cfg-target-vendor, ↵Mazdak Farrokhzad-4/+2
r=joshtriplett,Centril Stabilize cfg_target_vendor This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates. This functionality was added back in 2015 in #28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in #24777, never behind a feature_gate, and insta-stable at 1.1.0. The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs). Closes #29718
2019-01-14Stabilize `cfg_target_vendor`, #29718Jethro Beekman-4/+2
2019-01-14Auto merge of #57387 - euclio:nonstandard-style-suggestions, r=oli-obkbors-5/+7
Use structured suggestions for nonstandard style lints This PR modifies the lints in the nonstandard_style group to use structured suggestions. Note that there's a bit of tricky span calculation going on for the `crate_name` attribute. It also simplifies the code a bit: I don't think the "fallback" suggestions for these lints can actually be triggered. Fixes #48103. Fixes #52414.
2019-01-13Recover from item trailing semicolonEsteban Küber-24/+35
2019-01-14Make `TokenStream` use `Option`.Nicholas Nethercote-50/+45
Because that's the more typical way of representing an all-or-nothing type.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 23:28:46 +0000