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 E0379 check from typeck to ast validation #35480

Merged
merged 3 commits into from
Aug 30, 2016

Conversation

KiChjang
Copy link
Member

@KiChjang KiChjang commented Aug 8, 2016

Part of #35233.
Extension of #35338, #35364.
Fixes #35404.

r? @jonathandturner

@@ -94,7 +94,7 @@ impl<'a> MacResult for ParserAnyMacro<'a> {
let mut parser = self.parser.borrow_mut();
match parser.token {
token::Eof => break,
_ => ret.push(panictry!(parser.parse_impl_item()))
_ => ret.push(panictry!(parser.parse_impl_item(false)))
Copy link
Member Author

@KiChjang KiChjang Aug 8, 2016

Choose a reason for hiding this comment

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

Someone should double-check this - make_items should cover the case for macro trait impl fns and trait fns, so when make_impl_items is called, we can be certain that this is going to be a plain impl (i.e. impl without traits), hence this here is false.

@petrochenkov
Copy link
Contributor

@KiChjang
Checks performed in the parser can be overridden by syntax extensions (and occasionally macros), so we have a special pass instead that runs after expansion: https://github.com/rust-lang/rust/blob/master/src/librustc_passes/ast_validation.rs
This check is a perfect candidate for moving there.

@KiChjang KiChjang force-pushed the e0379-bonus branch 2 times, most recently from a552d03 to 7912ae2 Compare August 10, 2016 10:07
@KiChjang KiChjang changed the title Move E0379 check from typeck to parser Move E0379 check from typeck to ast validation Aug 10, 2016
@KiChjang
Copy link
Member Author

Moved the error from the parser to the ast validator.

@KiChjang
Copy link
Member Author

r? @jonathandturner

@@ -819,14 +819,10 @@ pub fn check_item_body<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>, it: &'tcx hir::Item) {
check_const(ccx, trait_item.span, &expr, trait_item.id)
}
hir::MethodTraitItem(ref sig, Some(ref body)) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add an assertion here that the fn is not const? (and maybe a comment pointing out that this is checked in the AST validator?)

Copy link
Contributor

Choose a reason for hiding this comment

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

But that will cause ICEs in erroneous code - the error in the validation pass is not fatal and compilation continues until type checking is done.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this would cause an ICE with const unsafe fn.

@nikomatsakis
Copy link
Contributor

r? @nikomatsakis

@nikomatsakis
Copy link
Contributor

@KiChjang

Could you show me where a span is created for an AST/HIR node? (probably not doing in this PR, but is good to know nonetheless)

Yes, that is generally in the parser (and, in that context, it's ok to do subtraction of this kind, though always a bit sketchy -- but in any case there we know that macro expansion hasn't happened yet, so the spans of different files and so forth are not mixed up). If you look in the parser, you'll see that it tracks lo (start points) and so forth and constructs spans and sticks them into various AST/HIR nodes.

If we wanted to track the span of just this keyword, then, I would probably change the AST to have Spanned<Constness> instead of Constness -- the type-checker will then guide you to the place that you have to add the span in the parser. (You'll also have to make misc changes elsewhere as a result, typically changing constness to constness.node (to skip past the span).)

@nikomatsakis
Copy link
Contributor

OK, sorry, forget the assertions, you're right :)

@nikomatsakis
Copy link
Contributor

In that case, can you just add some comments?

@nikomatsakis
Copy link
Contributor

Meh, I guess that's not necessary.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Aug 10, 2016

(To be clear, I'd still like to see the "span munging" changed.)

@KiChjang
Copy link
Member Author

Just a heads up, I've changed my mind. I'll be incorporating the changes to make Spanned<Constness> possible.

@KiChjang
Copy link
Member Author

Okay, I've made it so that all Constness fields in the ast/hir are all Spanned<Constness> instead.

@nikomatsakis
Copy link
Contributor

@KiChjang this all looks good; one thought is that if you convert the test into a ui test, we would be able to see (in the test) that the span is correct (right now the test harness is only checking line-numbers). There is some advice for writing ui tests (and generated the reference files) in src/test/ui/README.md.

What do you think?

@petrochenkov
Copy link
Contributor

Adding a span to constness seems pretty random. Why does it have a span while unsafety doesn't, for example. Many more important AST fragments, like match arms, don't have spans. What is the general policy here?
Spans are heavy enough (3 * u32), @KiChjang have you checked if sizes of Item/ImplItem/TraitItem changed? Is an improvement to one error message important enough to pay the price if they did?
(Of course, It would be ideal to have spans for all tokens, but that would blow up the AST/HIR size unless some smart scheme is used, which is not the case now.)
Also, this is a plugin-breaking change now.

@sophiajt
Copy link
Contributor

@petrochenkov - there can be multiple PRs that address different issues, so a later PR could add a span to unsafe, for example.

cc @nikomatsakis - since we were just chatting about AST nodes getting spans.

There may be a cost, which hopefully we can detect and address it if any exists, but the ergonomics of being able to have the spans and give better error messages is helpful.

@KiChjang
Copy link
Member Author

@nikomatsakis I'm fine with adding them to this PR, but I think we'll need to make it so that everyone working on #35233 should also write UI tests, if they have tightened the spans for some errors.

@nikomatsakis
Copy link
Contributor

@petrochenkov we are already somewhat inconsistent about where we include spans -- e.g., we sometimes put spans on identifiers, sometimes not. It seems... ok to me.

@@ -5775,7 +5783,9 @@ impl<'a> Parser<'a> {
// FUNCTION ITEM
self.bump();
let (ident, item_, extra_attrs) =
self.parse_item_fn(Unsafety::Normal, Constness::NotConst, Abi::Rust)?;
self.parse_item_fn(Unsafety::Normal,
dummy_spanned(Constness::NotConst),
Copy link
Contributor

Choose a reason for hiding this comment

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

Also here.

@KiChjang
Copy link
Member Author

Dummy spans removed from parser.rs.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Aug 18, 2016

📌 Commit 9fae2f3 has been approved by nikomatsakis

@KiChjang
Copy link
Member Author

Rebased.

@sophiajt
Copy link
Contributor

Huh, looks like a test in the src/libsyntax/parse/mod.rs needs updating?

test parse::tests::parse_fundecl ... FAILED

@KiChjang
Copy link
Member Author

Fixed the unit test in the latest force-push.

@sophiajt
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Aug 22, 2016

📌 Commit b5b667d has been approved by jonathandturner

@sophiajt
Copy link
Contributor

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Aug 22, 2016

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Aug 22, 2016

📌 Commit b5b667d has been approved by nikomatsakis

@jseyfried
Copy link
Contributor

@bors r-
This is a syntax-[breaking-change] and will land in the next batch (c.f. #31645 (comment)).

jseyfried added a commit to jseyfried/rust that referenced this pull request Aug 28, 2016
bors added a commit that referenced this pull request Aug 30, 2016
Batch up libsyntax breaking changes

Batch of the following syntax-[breaking-change] changes:
 - #35591: Add a field `span: Span` to `ast::Generics`.
 - #35618: Remove variant `Mod` of `ast::PathListItemKind` and refactor the remaining variant `ast::PathListKind::Ident` to a struct `ast::PathListKind_`.
 - #35480: Change uses of `Constness` in the AST to `Spanned<Constness>`.
  - c.f. `MethodSig`, `ItemKind`
 - #35728: Refactor `cx.pat_enum()` into `cx.pat_tuple_struct()` and `cx.pat_path()`.
 - #35850: Generalize the elements of lists in attributes from `MetaItem` to a new type `NestedMetaItem` that can represent a `MetaItem` or a literal.
 - #35917: Remove traits `AttrMetaMethods`, `AttributeMethods`, and `AttrNestedMetaItemMethods`.
  - Besides removing imports of these traits, this won't cause fallout.
 - Add a variant `Union` to `ItemKind` to future proof for `union` (c.f. #36016).
 - Remove inherent methods `attrs` and `fold_attrs` of `Annotatable`.
  - Use methods `attrs` and `map_attrs` of `HasAttrs` instead.

r? @Manishearth
@bors bors merged commit e46b09a into rust-lang:master Aug 30, 2016
@KiChjang KiChjang deleted the e0379-bonus branch August 30, 2016 16:53
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.

None yet

7 participants