Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a note for unclosed delimiters #10641

Merged
merged 1 commit into from
Nov 25, 2013
Merged

Add a note for unclosed delimiters #10641

merged 1 commit into from
Nov 25, 2013

Conversation

emberian
Copy link
Member

Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.

Closes #10636

// previous unclosed delimiters could actually be closed! The parser just hasn't
// gotten to them yet.
p.open_braces.iter().last().map(|sp| p.span_note(*sp, "Unclosed delimiter"));
p.fatal(format!("Incorrect close delimiter: `{}`", p.this_token_to_str()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the conventional error formatting with a lower-case leading letter?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it? I honestly haven't noticed. Do we have a style guide for this sort
of thing?

On Sun, Nov 24, 2013 at 9:30 PM, Huon Wilson notifications@github.comwrote:

In src/libsyntax/parse/parser.rs:

@@ -2086,15 +2086,13 @@ impl Parser {
fn parse_non_delim_tt_tok(p: &Parser) -> token_tree {
maybe_whole!(deref p, nt_tt);
match *p.token {

  •          token::RPAREN | token::RBRACE | token::RBRACKET
    
  •          => {
    
  •            p.fatal(
    
  •                format!(
    
  •                    "incorrect close delimiter: `{}`",
    
  •                    p.this_token_to_str()
    
  •                )
    
  •            );
    
  •          }
    
  •          token::RPAREN | token::RBRACE | token::RBRACKET => {
    
  •              // This is a conservative error: only report the last unclosed delimiter. The
    
  •              // previous unclosed delimiters could actually be closed! The parser just hasn't
    
  •              // gotten to them yet.
    
  •              p.open_braces.iter().last().map(|sp| p.span_note(*sp, "Unclosed delimiter"));
    
  •              p.fatal(format!("Incorrect close delimiter: `{}`", p.this_token_to_str()));
    

Isn't the conventional error formatting with a lower-case leading letter?


Reply to this email directly or view it on GitHubhttps://github.com//pull/10641/files#r7881939
.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it probably is.

On Sun, Nov 24, 2013 at 9:30 PM, Corey Richardson corey@octayn.net wrote:

Is it? I honestly haven't noticed. Do we have a style guide for this sort
of thing?

On Sun, Nov 24, 2013 at 9:30 PM, Huon Wilson notifications@github.comwrote:

In src/libsyntax/parse/parser.rs:

@@ -2086,15 +2086,13 @@ impl Parser {
fn parse_non_delim_tt_tok(p: &Parser) -> token_tree {
maybe_whole!(deref p, nt_tt);
match *p.token {

  •          token::RPAREN | token::RBRACE | token::RBRACKET
    
  •          => {
    
  •            p.fatal(
    
  •                format!(
    
  •                    "incorrect close delimiter: `{}`",
    
  •                    p.this_token_to_str()
    
  •                )
    
  •            );
    
  •          }
    
  •          token::RPAREN | token::RBRACE | token::RBRACKET => {
    
  •              // This is a conservative error: only report the last unclosed delimiter. The
    
  •              // previous unclosed delimiters could actually be closed! The parser just hasn't
    
  •              // gotten to them yet.
    
  •              p.open_braces.iter().last().map(|sp| p.span_note(*sp, "Unclosed delimiter"));
    
  •              p.fatal(format!("Incorrect close delimiter: `{}`", p.this_token_to_str()));
    

Isn't the conventional error formatting with a lower-case leading letter?


Reply to this email directly or view it on GitHubhttps://github.com//pull/10641/files#r7881939
.

Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.

Closes #10636
bors added a commit that referenced this pull request Nov 25, 2013
Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.

Closes #10636
@bors bors closed this Nov 25, 2013
@bors bors merged commit ab19861 into rust-lang:master Nov 25, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 23, 2023
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 23, 2023
Add size-parameter to unecessary_box_returns

Fixes rust-lang#10641

This adds a configuration-knob to the `unecessary_box_returns`-lint which allows _not_ linting a `fn() -> Box<T>` if `T` is "large". The default byte size above which we no longer lint is 128 bytes (due to rust-lang/rust-clippy#4652 (comment), also used in rust-lang#9373). The overall rational is given in rust-lang#10641.

---

changelog: Enhancement: [`unnecessary_box_returns`]: Added new lint configuration `unnecessary-box-size` to set the maximum size of `T` in `Box<T>` to be linted
[rust-lang#10651](rust-lang/rust-clippy#10651)
<!-- changelog_checked -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve error about close delimiter
3 participants