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

Implement another internal lints #61545

Merged
merged 8 commits into from
Jul 5, 2019
Merged

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Jun 5, 2019

cc #49509

This adds two one internal lints:

  1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the {declare,impl}_lint_pass macro is used to implement lint passes. cc Reduce repetition in librustc(_lint) wrt. impl LintPass by using macros #59669
  2. USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in Add compiler-internal lints #49509

With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?

TODO (not directly relevant for review):

r? @oli-obk

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 5, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Jun 5, 2019

not sure yet, if this works or how to query for rustc_private

Untested: tcx.stability().active_features.contains(&sym::rustc_private)

@flip1995
Copy link
Member Author

flip1995 commented Jun 5, 2019

The relevant code for this is in librustc_interface, so I don't think, that I have a TyCtxt at this point.

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

Ok, I did not foresee the fallout that TyCtxtAt would have. I'm going to review those in detail some time this week.

impl EarlyLintPass for LintPassImpl {
fn check_item(&mut self, cx: &EarlyContext<'_>, item: &Item) {
if let ItemKind::Impl(_, _, _, _, Some(lint_pass), _, _) = &item.node {
if !lint_pass.path.span.ctxt().outer_expn_info().is_some() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess any macro is better than none, checking for declare_lint_pass! or impl_lint_pass! specifically is overkill?

Copy link
Member Author

Choose a reason for hiding this comment

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

Didn't thought of specifically checking for these macros. I'll change that (since it's not much work), but don't think that there will be more lint findings.

src/librustc/ty/util.rs Outdated Show resolved Hide resolved
src/librustc_mir/interpret/eval_context.rs Outdated Show resolved Hide resolved
@rust-highfive
Copy link
Collaborator

The job mingw-check of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:01244ea2:start=1559744409378636692,finish=1559744412997065327,duration=3618428635
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:06:31]     Checking syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:06:32]     Checking rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:07:18]     Checking syntax_ext v0.0.0 (/checkout/src/libsyntax_ext)
[00:07:43] error[E0061]: this function takes 2 parameters but 1 parameter was supplied
[00:07:43]    --> src/librustc/ty/query/plumbing.rs:173:34
[00:07:43]     |
[00:07:43] 173 |                   let result = job.r#await(tcx);
[00:07:43]     | 
[00:07:43]     | 
[00:07:43]    ::: src/librustc/ty/query/job.rs:78:5
[00:07:43]     |
[00:07:43] 78  | /     pub(super) fn r#await<'lcx>(
[00:07:43] 79  | |         &self,
[00:07:43] 80  | |         tcx: TyCtxt<'_, 'tcx, 'lcx>,
[00:07:43] ...   |
[00:07:43] 99  | |         })
[00:07:43] 100 | |     }
[00:07:43]     | |_____- defined here
[00:07:43]     | |_____- defined here
[00:07:43] 
[00:07:43] error[E0308]: mismatched types
[00:07:43]    --> src/librustc/ty/query/plumbing.rs:177:67
[00:07:43]     |
[00:07:43] 177 |                     return TryGetJob::Cycle(Q::handle_cycle_error(tcx, cycle));
[00:07:43]     |                                                                   |
[00:07:43]     |                                                                   |
[00:07:43]     |                                                                   expected struct `ty::context::TyCtxt`, found struct `ty::query::TyCtxtAt`
[00:07:43]     |                                                                   help: consider dereferencing the type: `*tcx`
[00:07:43]     = note: expected type `ty::context::TyCtxt<'_, '_, '_>`
[00:07:43]                found type `ty::query::TyCtxtAt<'a, 'tcx, '_>`
[00:07:43] 
[00:07:47] error: aborting due to 2 previous errors
---
travis_time:end:02409f3c:start=1559744892677729089,finish=1559744892684576331,duration=6847242
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:01b21ecc
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:001ad100
travis_time:start:001ad100
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:13caeea8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive
Copy link
Collaborator

The job mingw-check of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:0032e838:start=1559757481377297142,finish=1559757485177361245,duration=3800064103
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:05:29]     Checking syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:05:30]     Checking rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:06:17]     Checking syntax_ext v0.0.0 (/checkout/src/libsyntax_ext)
[00:06:43] error[E0061]: this function takes 2 parameters but 1 parameter was supplied
[00:06:43]    --> src/librustc/ty/query/plumbing.rs:173:34
[00:06:43]     |
[00:06:43] 173 |                   let result = job.r#await(tcx);
[00:06:43]     | 
[00:06:43]     | 
[00:06:43]    ::: src/librustc/ty/query/job.rs:78:5
[00:06:43]     |
[00:06:43] 78  | /     pub(super) fn r#await<'lcx>(
[00:06:43] 79  | |         &self,
[00:06:43] 80  | |         tcx: TyCtxt<'_, 'tcx, 'lcx>,
[00:06:43] ...   |
[00:06:43] 99  | |         })
[00:06:43] 100 | |     }
[00:06:43]     | |_____- defined here
---
travis_time:end:1d33f5f0:start=1559757906713613376,finish=1559757906719258214,duration=5644838
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:258ef3a2
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0e4de696
travis_time:start:0e4de696
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:1168d143
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors
Copy link
Contributor

bors commented Jun 6, 2019

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

@oli-obk
Copy link
Contributor

oli-obk commented Jun 8, 2019

Ok, so the current fallout seems overly excessive, I did not anticipate that. How hard do you think it would be to change the lint to only complain about functions that have both TyCtxt and Span in their arguments and do tcx.at(span) in their body?

@flip1995
Copy link
Member Author

flip1995 commented Jun 8, 2019

That would just require to add a visitor for the function body searching for calls to .at() on TyCtxt types. So I could implement this.

On the other hand, I just searched for "tcx.at" with the GitHub search and there would be just about 5 functions that would trigger this lint then.

@oli-obk
Copy link
Contributor

oli-obk commented Jun 8, 2019

Ah yes, I expect that not much will trigger this at the moment, but changing those functions' APIs may again cause other functions to trigger the lint and so on.

I guess it's not that important. Lets just remove the lint from the ideas list, it's too prone to false positives or weird situations

@flip1995
Copy link
Member Author

I removed the commits for the TyCtxtAt lint, but backed it up in https://github.com/flip1995/rust/tree/tyctxt_span_args

Now only the TODOs are left to implement.

@flip1995
Copy link
Member Author

I tried to enable -Winternal in src/bootstrap/bin/rustc.rs. The main problem is the lint default_hash_types. I see 3 courses of action here:

  1. Only trigger this lint on crates with a dependency on rustc_data_structures
  2. Use rustc_data_structures in more crates (e.g. libterm, libproc_macro)
  3. Add #![allow(default_hash_types)] to crates without this dependency

The alternative would be to leave it as is and activate internal lints crate wise.

@oli-obk
Copy link
Contributor

oli-obk commented Jun 14, 2019

Only trigger this lint on crates with a dependency on rustc_data_structures

This is probably too hard to do. We'd need access to the dependencies, which we don't have yet while adding the lint to the list of lints to run (we need a TyCtxt for that I think).

The alternative would be to leave it as is and activate internal lints crate wise.

Imo keeping this on a crate-by-crate basis is ok.

@petrochenkov
Copy link
Contributor

@flip1995
You can enable enable -Winternal in src/bootstrap/bin/rustc.rs for crates that starts_with("rustc") || starts_with("syntax").
There are a couple of false-positives and false-negatives, but that's still much much fewer per-crate annotations.

On a related note, it would be nice to rename internal into rustc_internal.

@oli-obk
Copy link
Contributor

oli-obk commented Jun 14, 2019

On a related note, it would be nice to rename internal into rustc_internal.

We have lint tools, so we could even have rustc::internal

Copy link
Member Author

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

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

On moving the -Winternal to bootstrap the two crates

  • libfmt_macros
  • libarena

don't get linted anymore. Is this okay or should they be added specifically to bootstrap?

@@ -1,5 +1,6 @@
#![feature(proc_macro_hygiene)]
#![deny(rust_2018_idioms)]
#![allow(default_hash_types)]
Copy link
Member Author

Choose a reason for hiding this comment

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

Should we allow default_hash_types here or use rustc_data_structures in rustc_macros?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure, is rustc_data_structures using rustc_macros for proc macros?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope rustc_data_structures doesn't depend on rustc_macros.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, adding a further dependency to rustc_macros seems fine to me then.

Copy link
Contributor

Choose a reason for hiding this comment

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

Please, measure the build time.
Speedups from using FxHashMap in the proc macros are unlikely to outweigh the build parallelism lost due to the introduced dependency.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. HashSet is only used once in rustc_macros to verify, that no symbols are duplicated.

let mut keys = HashSet::<String>::new();
let mut check_dup = |str: &str| {
if !keys.insert(str.to_string()) {
panic!("Symbol `{}` is duplicated", str);
}
};

src/librustc/lint/internal.rs Outdated Show resolved Hide resolved
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:020a9d38:start=1560784114842155964,finish=1560784115798356393,duration=956200429
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
travis_time:start:test_assembly
Check compiletest suite=assembly mode=assembly (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:10:31] 
[01:10:31] running 9 tests
[01:10:31] iiiiiiiii
[01:10:31] 
[01:10:31]  finished in 0.154
[01:10:31] travis_fold:end:test_assembly

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-gdb+lldb (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:10:47] 
[01:10:47] running 122 tests
[01:11:12] .iiiii...i.....i..i...i..i.i.i..i.ii..i.i.....i..i....i..........iiii..........i...ii...i.......ii.i 100/122
[01:11:17] .i.i......iii.i.....ii
[01:11:17] 
[01:11:17]  finished in 29.823
[01:11:17] travis_fold:end:test_debuginfo

---
[01:23:09]    Compiling semver v0.9.0
[01:23:09]    Compiling rustc_version v0.2.3
[01:23:09] error[E0602]: unknown lint: `rustc::internal`
[01:23:09]   |
[01:23:09]   = note: requested on the command line with `-W rustc::internal`
[01:23:10] error: aborting due to previous error
[01:23:10] 
[01:23:10] For more information about this error, try `rustc --explain E0602`.
[01:23:10] error: Could not compile `rustc_version`.
[01:23:10] error: Could not compile `rustc_version`.
[01:23:10] 
[01:23:10] To learn more, run the command again with --verbose.
[01:23:10] 
[01:23:10] 
[01:23:10] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "alloc" "--" "--quiet"
[01:23:10] 
[01:23:10] 
[01:23:10] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:23:10] Build completed unsuccessfully in 1:16:11

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

src/bootstrap/bin/rustc.rs Outdated Show resolved Hide resolved
@flip1995 flip1995 changed the title [WIP] Implement two more internal lints [WIP] Implement another internal lints Jun 23, 2019
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-tools of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:44:19] test client_test_simple_workspace ... ok
[01:44:19] test client_workspace_symbol_duplicates ... ok
[01:44:46] thread panicked while panicking. aborting.
[01:44:46] [2019-07-01T11:55:13Z ERROR rls::server] Can't read message
[01:44:46] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', src/libcore/result.rs:999:5
[01:44:46] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:44:46] error: process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/client-b5d970883c131c9a` (signal: 4, SIGILL: illegal instruction)
[01:44:46] 
[01:44:46] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--manifest-path" "/checkout/src/tools/rls/Cargo.toml" "--features" "rustc-workspace-hack/all-static" "--"
[01:44:46] expected success, got: exit code: 101
[01:44:46] 
---
travis_time:end:0d8f5a5f:start=1561982478197543450,finish=1561982478393244277,duration=195700827
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:14aad7ea
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:021483bb
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 1, 2019
@flip1995
Copy link
Member Author

flip1995 commented Jul 1, 2019

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }'

Spurious? 🤔 This PR doesn't add an unwrap() call.

@mati865
Copy link
Contributor

mati865 commented Jul 1, 2019

Probably another spurious RLS test #62225

@flip1995
Copy link
Member Author

flip1995 commented Jul 3, 2019

ping @oli-obk. Anything I can do here? I already have the next internal lint in the pipeline, but this needs to get merged first 😄

@petrochenkov
Copy link
Contributor

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Jul 5, 2019

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

  • This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
  • There's another pull request that is currently being tested, blocking this pull request: Remove io::Result from syntax::print #62099

@bors
Copy link
Contributor

bors commented Jul 5, 2019

📌 Commit d0625a3 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 5, 2019
@bors
Copy link
Contributor

bors commented Jul 5, 2019

⌛ Testing commit d0625a3 with merge d8999f8dfb552c48656537a6c8bbe4da284d0a52...

@Centril
Copy link
Contributor

Centril commented Jul 5, 2019

@bors retry yielding to r0llup.

Centril added a commit to Centril/rust that referenced this pull request Jul 5, 2019
Implement another internal lints

cc rust-lang#49509

This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc rust-lang#59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in rust-lang#49509~~

~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~

TODO (not directly relevant for review):
- [ ] rust-lang#59316 (comment) (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] rust-lang#61735 (comment)
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros

r? @oli-obk
Centril added a commit to Centril/rust that referenced this pull request Jul 5, 2019
Implement another internal lints

cc rust-lang#49509

This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc rust-lang#59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in rust-lang#49509~~

~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~

TODO (not directly relevant for review):
- [ ] rust-lang#59316 (comment) (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] rust-lang#61735 (comment)
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros

r? @oli-obk
Centril added a commit to Centril/rust that referenced this pull request Jul 5, 2019
Implement another internal lints

cc rust-lang#49509

This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc rust-lang#59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in rust-lang#49509~~

~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~

TODO (not directly relevant for review):
- [ ] rust-lang#59316 (comment) (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] rust-lang#61735 (comment)
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros

r? @oli-obk
bors added a commit that referenced this pull request Jul 5, 2019
Rollup of 13 pull requests

Successful merges:

 - #61545 (Implement another internal lints)
 - #62110 (Improve -Ztime-passes)
 - #62133 (Feature gate `rustc` attributes harder)
 - #62158 (Add MemoryExtra in InterpretCx constructor params)
 - #62168 (The (almost) culmination of HirIdification)
 - #62193 (Create async version of the dynamic-drop test)
 - #62369 (Remove `compile-pass` from compiletest)
 - #62380 (rustc_target: avoid negative register counts in the SysV x86_64 ABI.)
 - #62381 (Fix a typo in Write::write_vectored docs)
 - #62390 (Update README.md)
 - #62396 (remove Scalar::is_null_ptr)
 - #62406 (Lint on invalid values passed to x.py --warnings)
 - #62414 (Remove last use of mem::uninitialized in SGX)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jul 5, 2019

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 5, 2019
@bors bors merged commit d0625a3 into rust-lang:master Jul 5, 2019
Centril added a commit to Centril/rust that referenced this pull request Jul 7, 2019
…lacrum

rustbuild: Cleanup global lint settings

Lint settings do not depend on `if let Some(target) = target` in any way, so they are moved out of that clause.

Internal lints now respect `RUSTC_DENY_WARNINGS`.

Crate name treatment is cleaned up a bit.

cc rust-lang#61545 @flip1995
r? @Mark-Simulacrum
@flip1995 flip1995 deleted the internal_lints branch July 9, 2019 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants