prohibit types named dyn`

[nikomatsakis]

Fixes #50405

cc @rust-lang/lang -- I took the liberty of extending the "no traits named dyn" rule to be "no types named dyn". It seemed more uniform. People ok with that?

Should we do a crater run for this?

r? @petrochenkov

[nikomatsakis]

Some relevant searches for text across crates.io:

• trait dyn -- nothing
• struct dyn -- nothing
• enum dyn -- nothing
• union dyn -- nothing
• type dyn -- nothing

[rust-highfive]

The job x86_64-gnu-llvm-3.9 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:23:24] 
[01:23:24] failures:
[01:23:24] 
[01:23:24] ---- /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md - Rust_Compiler_Error_Index::E0705 (line 11346) stdout ----
[01:23:24] error[E0705]: types cannot be named `dyn`
[01:23:24]  --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:11347:1
[01:23:24]   |
[01:23:24] 3 | trait dyn { }
[01:23:24] 
[01:23:24] 
[01:23:24] thread '/checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md - Rust_Compiler_Error_Index::E0705 (line 11346)' panicked at 'Some expected error codes were not found: ["E0695"]', librustdoc/test.rs:332:13
[01:23:24] 
[01:23:24] 
[01:23:24] failures:
[01:23:24]     /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md - Rust_Compiler_Error_Index::E0705 (line 11346)
---
[01:23:24] 
[01:23:24] 
[01:23:24] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:23:24] Build completed unsuccessfully in 0:42:49
[01:23:24] Makefile:58: recipe for target 'check' failed
[01:23:24] make: *** [check] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:03796101
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

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)

[kennytm]

Please also add a test to ensure mod dyn (used in goblin) still works?

Also, ensure extern { type dyn; } is forbidden?

[nikomatsakis]

@kennytm

Please also add a test to ensure mod dyn (used in goblin) still works?

OK -- though I think we have a test for that already. Let me see if I can find it. Well, we have this, which isn't that great:

https://github.com/rust-lang/rust/blob/master/src/test/compile-fail/dyn-trait-compatibility.rs

Also, ensure extern { type dyn; } is forbidden?

Ah, good catch.

[petrochenkov]

Ugh.
This is a covering up a wart with a larger wart, this error is so artificial and unnecessary it hurts my aesthetic feelings even despite its total insignificance.
We should rather close #50405 as not-an-issue immediately and avoid spending any more time on it.

I agree that it makes sense to disallow trait dyn if you can't impl dyn.

impl self::dyn for ... { ... } is the solution for this particular imaginary problem.

[petrochenkov]

If the true goal is to turn dyn from a context-sensitive identifier into a keyword, then we should do that, rather than attempting these "covert advances".

[nikomatsakis]

If the true goal is to turn dyn from a context-sensitive identifier into a keyword, then we should do that, rather than attempting these "covert advances".

I think that -- in retrospect -- I wish we had only enabled dyn in the new Edition and made it a true keyword. However, here we are. Live and learn and all that. That said, I don't think there is a "hidden agenda" here or anything. We're trying to allow people to use dyn as a module name, because that is used in practice, but don't particular care to support other (non-idiomatic) usage.

That said, you're right that there exist other workarounds one could use -- impl self::dyn for Foo or perhaps impl r#dyn for Foo? -- so maybe it's fine to just let you declare traits and things named dyn. I don't have a strong opinion, curious to hear from @rust-lang/lang

[mark-i-m]

I wish we had only enabled dyn in the new Edition and made it a true keyword.

We can still do it, but I'm not sure if it matters much now since we already have to support this mechanism.

Also what about things like

use foo::bar as dyn;

[withoutboats]

I don't care what we do here and mostly feel that the amount of attention its receiving is a misallocation of resources to an artificial issue, so I'd hope this could be decided without any protracted further discussion.

[nikomatsakis]

OK, I'm convinced we can just close this PR and the original issue as "here is the way to implement a trait named dyn".