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

Move errors from libsyntax into their own crate #34403

Closed
wants to merge 17 commits into from

Conversation

sophiajt
Copy link
Contributor

This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors). This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.

As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos). While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.

r? @alexcrichton

@nagisa
Copy link
Member

nagisa commented Jun 21, 2016

potentially plugin-[breaking-change]

//!
//! This API is completely unstable and subject to change.

#![crate_name = "syntax_pos"]
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if it's too late for this, but maybe this crate should be called rustc_codemap to follow the trend of rustc_* and it's basically where the module came from as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Me and @alexcrichton chatted offline a bit about this. A rustc_* name may make sense but we couldn't think of a good fit. Will probably move that way in the future, but the name seems good enough for now.

@alexcrichton
Copy link
Member

Looks good to me! cc @Manishearth, is there a protocol for negotiating landing these kinds of changes nowadays?

@sophiajt
Copy link
Contributor Author

thanks @alexcrichton - updated with your suggestions (minus the name one which we chatted about offline).

@Manishearth
Copy link
Member

(travis fails)

@alexcrichton yes! you just say @manishearth: r+ or something like that, cc #31645, and then wait for a breaking batch. If the PR is bitrot-susceptible or is something otherwise urgent, let me know and I will make a batch, whilst encouraging others to squeeze their own breaking changes in. Fortunately, such a batch is already in progress right now (waiting on a fixup/review of #34316), so this should just fit in.

@Manishearth
Copy link
Member

@erickt @dtolnay fyi this looks like a major bit of breakage for you. I will let the breaking batch PR simmer for a day (once it exists) before trying to merge it so that you get ample time to get this to work properly. Let me know if you need more time.

@erickt
Copy link
Contributor

erickt commented Jun 22, 2016

@Manishearth: yikes, this is definitely going to cause some syntex fallout. Thanks for the heads up.

@sophiajt
Copy link
Contributor Author

@Manishearth - thanks! This PR touches a fair number of files, so I'm all for batching it up with the other breaking changes. With luck I'll have fixed the last of the travis issues...

@alexcrichton
Copy link
Member

@Manishearth yeah this is good to go whenever at this point (r+ from me)

@jonathandturner looks like the travis failure may be legit?

@sophiajt
Copy link
Contributor Author

@alexcrichton - it's legit, chasing down the last(?) of the errors as we speak

@GuillaumeGomez
Copy link
Member

Once merged, I'll add missing error codes into libsyntax (FINALLY!). Very nice work! 👍

@bors
Copy link
Contributor

bors commented Jun 23, 2016

☔ The latest upstream changes (presumably #34253) made this pull request unmergeable. Please resolve the merge conflicts.

@jseyfried
Copy link
Contributor

@jonathandturner If we re-export syntax_pos in syntax::diagnostics and re-export rustc_errors in syntax::diagnostics, would this no longer by a syntax-[breaking-chage]?

I think it would be a good idea to re-export everything relevant to plugin authors in libsyntax anyway.

@sophiajt
Copy link
Contributor Author

@jseyfried - Hmm I think the idea is more "refactor so that we can make deeper changes". This has the unfortunate side effect that it may break plugin authors from time to time. The current errors system has layers of different styles and approaches, but I'd like to get it simplified to one style that we can use and then output multiple types of output.

@jseyfried
Copy link
Contributor

@jonathandturner
Agreed that a simpler error system would be excellent, even if it breaks plugin authors.

Would we ever not be able to re-export everything relevant to plugin authors in libsyntax? I think re-exporting everything in libsyntax would be a good idea regardless of how the error system ends up being structured, if this is possible.

Also, perhaps we could add the re-exports for plugin authors in the PR but not use them in rustc itself? We could always remove the re-exports when we make deeper changes that would cause breakage for plugin authors anyway.

@sophiajt
Copy link
Contributor Author

@jseyfried - yeah, I can definitely do that. I think you're right that this would prevent immediate breakage. We can still give plugin authors a heads up that the further simplifications might break them down the road...

@jseyfried
Copy link
Contributor

Hopefully they know that -- we try to minimize and batch up plugin-[breaking-changes] but we still make them fairly often (c.f. #31645).

@sophiajt
Copy link
Contributor Author

Woot! Pinging @Manishearth - looks like we've passed travis and cut down the number of breaking changes for this patch.

@jseyfried
Copy link
Contributor

@jonathandturner Nice!

cut down the number of breaking changes

Are there any syntax-[breaking-changes] left? If so, what are they?

@sophiajt
Copy link
Contributor Author

@jseyfried - Ah good point. In theory, this should be source compatible with what we had before, though I'm not 100% sure (a fair bit got moved around). Still might be worth batching with breaking changes...

@jseyfried
Copy link
Contributor

@Manishearth what do you think?

@Manishearth
Copy link
Member

We still have the batch going on; @jseyfried want to finish it? Make a PR that includes this and send it to try. We can merge it tomorrow.

@jseyfried
Copy link
Contributor

@Manishearth I'll finish up #34424 (and include #34436) in a couple of hours.

jseyfried added a commit to jseyfried/rust that referenced this pull request Jun 25, 2016
…excrichton

This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors).  This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.

As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos).  While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.
bors added a commit that referenced this pull request Jun 26, 2016
Batch up libsyntax breaking changes

Batch of the following syntax-[breaking-change] changes:
 - #34213: Add a variant `Macro` to `TraitItemKind`
 - #34368: Merge the variant `QPath` of `PatKind` into the variant `PatKind::Path`
 - #34385: Move `syntax::ast::TokenTree` into a new module `syntax::tokenstream`
 - #33943:
  - Remove the type parameter from `visit::Visitor`
  - Remove `attr::WithAttrs` -- use `attr::HasAttrs` instead.
  - Change `fold_tt`/`fold_tts` to take token trees by value and avoid wrapping token trees in `Rc`.
  - Remove the field `ctxt` of `ast::Mac_`
  - Remove inherent method `attrs()` of types -- use the method `attrs` of `HasAttrs` instead.
 - #34316:
  - Remove `ast::Decl`/`ast::DeclKind` and add variants `Local` and `Item` to `StmtKind`.
  - Move the node id for statements from the `StmtKind` variants to a field of `Stmt` (making `Stmt` a struct instead of an alias for `Spanned<StmtKind>`)
  - Rename `ast::ExprKind::Again` to `Continue`.
 - #34339: Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`
  - Use `.into()` in convert between `Vec<Attribute>` and `ThinVec<Attribute>`
  - Use autoderef instead of `.as_attr_slice()`
 - #34436: Remove the optional expression from `ast::Block` and instead use a `StmtKind::Expr` at the end of the statement list.
 - #34403: Move errors into a separate crate (unlikely to cause breakage)
bors added a commit that referenced this pull request Jun 27, 2016
Batch up libsyntax breaking changes

Batch of the following syntax-[breaking-change] changes:
 - #34213: Add a variant `Macro` to `TraitItemKind`
 - #34368: Merge the variant `QPath` of `PatKind` into the variant `PatKind::Path`
 - #34385: Move `syntax::ast::TokenTree` into a new module `syntax::tokenstream`
 - #33943:
  - Remove the type parameter from `visit::Visitor`
  - Remove `attr::WithAttrs` -- use `attr::HasAttrs` instead.
  - Change `fold_tt`/`fold_tts` to take token trees by value and avoid wrapping token trees in `Rc`.
  - Remove the field `ctxt` of `ast::Mac_`
  - Remove inherent method `attrs()` of types -- use the method `attrs` of `HasAttrs` instead.
 - #34316:
  - Remove `ast::Decl`/`ast::DeclKind` and add variants `Local` and `Item` to `StmtKind`.
  - Move the node id for statements from the `StmtKind` variants to a field of `Stmt` (making `Stmt` a struct instead of an alias for `Spanned<StmtKind>`)
  - Rename `ast::ExprKind::Again` to `Continue`.
 - #34339: Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`
  - Use `.into()` in convert between `Vec<Attribute>` and `ThinVec<Attribute>`
  - Use autoderef instead of `.as_attr_slice()`
 - #34436: Remove the optional expression from `ast::Block` and instead use a `StmtKind::Expr` at the end of the statement list.
 - #34403: Move errors into a separate crate (unlikely to cause breakage)
@bors
Copy link
Contributor

bors commented Jun 28, 2016

☔ The latest upstream changes (presumably #34424) made this pull request unmergeable. Please resolve the merge conflicts.

@jseyfried
Copy link
Contributor

@jonathandturner I believe this didn't get automatically marked as merged because of the above commit you added.

@sophiajt sophiajt closed this Jun 28, 2016
@sophiajt sophiajt deleted the move_liberror branch June 28, 2016 10:31
@GuillaumeGomez
Copy link
Member

So I can start my part of the work! :D

bors added a commit that referenced this pull request Jul 17, 2016
Simplify librustc_errors

This is part 2 of the error crate refactor, starting with #34403.

In this refactor, I focused on slimming down the error crate to fewer moving parts.  As such, I've removed quite a few parts and replaced the with simpler, straight-line code.  Specifically, this PR:

* Removes BasicEmitter
* Remove emit from emitter, leaving emit_struct
* Renames emit_struct to emit
* Removes CoreEmitter and focuses on a single Emitter
* Implements the latest changes to error format RFC (#1644)
* Removes (now-unused) code in emitter.rs and snippet.rs
* Moves more tests to the UI tester, removing some duplicate tests in the process

There is probably more that could be done with some additional refactoring, but this felt like it was getting to a good state.

r? @alexcrichton   cc: @Manishearth (as there may be breaking changes in stuff I removed/changed)
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.

9 participants