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

don't suggest placing use statements into expanded code #44215

Merged
merged 3 commits into from
Sep 21, 2017

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Aug 31, 2017

r? @nrc

fixes #44210

#[derive(Debug)]
struct Foo;

type X = Path;

will try to place use std::path::Path; between #[derive(Debug)] and struct Foo;

I am not sure how to obtain a span before the first attribute, because derive attributes are removed during expansion.

It would be trivial to detect this case and place the use after the item, but that would be somewhat weird I think.

@shepmaster shepmaster added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 1, 2017
@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 4, 2017

I need a decision on how to continue here.

  1. don't remove derive (currently causes infinite expansion, not sure how to fix)
  2. remove derive contents (lints about #[derive()] being bad, can tag somehow or simply allow empty derives)
  3. replace with #[removed_attribute_placeholder] and mark it as some internal NOP attribute which only exists for diagnostics

@petrochenkov
Copy link
Contributor

@oli-obk
Could you remind why issues like #44210 happen in the first place.
Why isn't the suggestion attached to Path?

All I remember is that everything worked okay some time ago, but then some "suggestion diagnostics reform" happened and issues like this started to appear.

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 6, 2017

These things happen, because we are not producing help messages telling you what to insert, but we are producing suggestions, which contain a span that is supposed to be replaced. The human readable interface then applies the replacement and prints it. If the span is bogus, we get things like these.

Figuring out where to place things can be difficult. Much more than I anticipated when I did the original change. But doing this is the right thing imo, because it will allow IDEs to enable users to insert missing import statements with a click

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 6, 2017

Why isn't the suggestion attached to Path?

What do you mean by that?

@petrochenkov
Copy link
Contributor

which contain a span that is supposed to be replaced

Ah, I see. So, the span for import suggestions is not span of Path, but span of the place (probably somewhere at the start of the file) into which these imports are supposed to be inserted.
This is good for tools, but it was a mistake to use this "insertion span" for user visible diagnostics, IMO.

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 10, 2017

This is good for tools, but it was a mistake to use this "insertion span" for user visible diagnostics, IMO.

We could differentiate between insertion suggestions and replacement suggestions by not showing surroundings for insertion suggestions (at least if they insert a whole new line)

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 14, 2017

We can also merge this (it will solve the visual bugs, but not the structured placement of the suggestions), and fix #44215 (comment) later

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 15, 2017

r? @arielb1 irc discussion seems to suggest some urgency on this. I can do changes until tuesday, then I'm on vacation.

My suggestion is to merge it as it is, and fix the structured json output later (the spans are wrong, the command line output can now never be wrong again barring missing expansion info on spans)

@rust-highfive rust-highfive assigned arielb1 and unassigned nrc Sep 15, 2017
@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 19, 2017

I will be on vacation starting now, so if there are any change requests, I won't be able to do anything about them until Rustfest.

The travis failure is bogus (not in the travis builder).

@arielb1
Copy link
Contributor

arielb1 commented Sep 19, 2017

r? @nrc

I don't know this area of the code

@rust-highfive rust-highfive assigned nrc and unassigned arielb1 Sep 19, 2017
@arielb1
Copy link
Contributor

arielb1 commented Sep 19, 2017

This is, however, an annoying beta regression. The beta deadline is less than 2 weeks from now. It would be nice to see what can be done to get this fixed for beta.

@nrc
Copy link
Member

nrc commented Sep 19, 2017

Yeah, this fix looks good to me, we can address making the IDE case perfect later, but this is already much better than before.

@nrc
Copy link
Member

nrc commented Sep 19, 2017

@bors: r+

@bors
Copy link
Contributor

bors commented Sep 19, 2017

📋 Looks like this PR is still in progress, ignoring approval

@oli-obk oli-obk changed the title WIP: don't suggest placing use statements into expanded code don't suggest placing use statements into expanded code Sep 19, 2017
@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 19, 2017

Removed WIP from title

@estebank
Copy link
Contributor

@bors r=nrc

@bors
Copy link
Contributor

bors commented Sep 21, 2017

📌 Commit f0e7a5b has been approved by nrc

@nikomatsakis nikomatsakis added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 21, 2017
@nikomatsakis
Copy link
Contributor

Nominating for backport as this fixes a stable-to-beta regression (#44566)

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. beta-accepted Accepted for backporting to the compiler in the beta channel. labels Sep 21, 2017
@bors
Copy link
Contributor

bors commented Sep 21, 2017

⌛ Testing commit f0e7a5b with merge 17f56c5...

bors added a commit that referenced this pull request Sep 21, 2017
don't suggest placing `use` statements into expanded code

r? @nrc

fixes #44210

```rust
#[derive(Debug)]
struct Foo;

type X = Path;
```

will try to place `use std::path::Path;` between `#[derive(Debug)]` and `struct Foo;`

I am not sure how to obtain a span before the first attribute, because derive attributes are removed during expansion.

It would be trivial to detect this case and place the `use` after the item, but that would be somewhat weird I think.
@bors
Copy link
Contributor

bors commented Sep 21, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: nrc
Pushing 17f56c5 to master...

@bors bors merged commit f0e7a5b into rust-lang:master Sep 21, 2017
@alexcrichton
Copy link
Member

@oli-obk or @nikomatsakis would y'all be willing to help out with the backport here? Apparentlythis doesn't apply cleanly

bors added a commit that referenced this pull request Sep 26, 2017
[beta] Backport accepted PRs to 1.21

Backport of:

- ~don't suggest placing `use` statements into expanded code #44215
- stabilize tcpstream_connect_timeout #44563
- stabilized iterator_for_each #44567
- travis: Move sccache to the us-west-1 region #44574
- stabilized ord_max_min #44593
- stabilized compiler_fences #44595
- ci: Upload/download from a new S3 bucket #44617
- stabilized needs_drop #44639
- Stabilized vec_splice and modified splice tracking issue #44640
- Backport libs stabilizations to 1.21 beta #44824
bors added a commit that referenced this pull request Oct 2, 2017
@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 9, 2017
@oli-obk oli-obk deleted the import_sugg branch November 13, 2017 07:31
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 24, 2021
Fix use placement for suggestions near main.

This fixes an edge case for the suggestion to add a `use`. When running with `--test`, the `main` function will be annotated with an `#[allow(dead_code)]` attribute. The `UsePlacementFinder` would end up using the dummy span of that synthetic attribute. If there are top-level inner attributes, this would place the `use` in the wrong position. The solution here is to ignore attributes with dummy spans.

In the process of working on this, I discovered that the `use_suggestion_placement` test was broken. `UsePlacementFinder` is unaware of active attributes. Attributes like `#[derive]` don't exist in the AST since they are removed. Fixing that is difficult, since the AST does not retain enough information. I considered trying to place the `use` towards the top of the module after any `extern crate` items, but I couldn't find a way to get a span for the start of a module block (the `mod` span starts at the `mod` keyword, and it seems tricky to find the spot just after the opening bracket and past inner attributes). For now, I just put some comments about the issue. This appears to have been a known issue in rust-lang#44215 where the test for it was introduced, and the fix seemed to be deferred to later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error suggestions for import contain erroneous derive
10 participants