[WIP] Implement RFC 1260

[F001]

This is my in-progress work to implement RFC 1260: main_reexport.

Tracking issue: #28937

There is a known problem that, I have no idea how to get the foreign function's signature if it is imported from another crate. Thus, the type check for this case is not done yet. I'd appreciate it if someone can provide some helps.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

@rust-lang/lang
This is one of the worst accepted RFCs that I've seen in terms of cost vs benefit.
It adds a weird corner case to the language and compiler while all it does is changing fn main() { my_fn() } to use my_fn as main;.
We should rather unaccept in than implement.

[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.

[00:05:27] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:05:28] tidy error: /checkout/src/test/ui/rfc-1260-main-reexport/with-args-fn.rs: missing trailing newline
[00:05:28] tidy error: duplicate error code: 135
[00:05:28] tidy error: /checkout/src/librustc/diagnostics.rs:506: E0135: r##"
[00:05:28] tidy error: /checkout/src/librustc/diagnostics.rs:2137: //  E0135,
[00:05:28] tidy error: duplicate error code: 133
[00:05:28] tidy error: /checkout/src/librustc_mir/diagnostics.rs:718: E0133: r##"
[00:05:28] tidy error: /checkout/src/librustc_typeck/diagnostics.rs:1547: E0133: r##"
[00:05:28] tidy error: duplicate error code: 134
[00:05:28] tidy error: /checkout/src/librustc/diagnostics.rs:484: E0134: r##"
[00:05:28] tidy error: /checkout/src/librustc/diagnostics.rs:2136: //  E0134,
[00:05:28] Expected a gate test for the feature 'main_reexport'.
[00:05:28] Hint: create a failing test file named 'feature-gate-main_reexport.rs'
[00:05:28]       in the 'ui' test suite, with its failures due to
[00:05:28]       missing usage of #![feature(main_reexport)].
[00:05:28] Hint: If you already have such a test and don't want to rename it,
[00:05:28]       you can also add a // gate-test-main_reexport line to the test file.
[00:05:28] tidy error: Found 1 features without a gate test.
[00:05:29] some tidy checks failed
[00:05:29] 
[00:05:29] 
[00:05:29] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:29] 
[00:05:29] 
[00:05:29] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:29] Build completed unsuccessfully in 0:02:02
[00:05:29] Build completed unsuccessfully in 0:02:02
[00:05:29] Makefile:79: recipe for target 'tidy' failed
[00:05:29] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:3f941200
$ 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)

[jonas-schievink]

This does seem like it adds a lot of corner cases in the compiler. For example, we already have error codes for doing use A as X; use B as X; as well as fn main<T>() {}. Those could be unified with the ones added by this PR.

Similarly, the distinction of "imported main" vs. "regular fn main" could be removed. It seems to me that main is currently rather special and from my naive model of how this part of rustc works it might be desirable to instead do the equivalent of "the item named main is the program's main function" and go through the regular resolve steps that will automatically handle use.

I disagree that this is a special case in the language itself, though. If we adopt the "the item named main is the program's main function" model this would be entirely consistent.

[eddyb]

One of the annoying bits is that main is type-checked specially - if we were to do this entirely separately, based on the type of the item that we've chosen as our main (which we'd refer to by DefId alone), then it should "just work", even cross-crate. I think we already use just the DefId to generate the function pointer to pass to libstd, so that part should be fine.

[F001]

@jonas-schievink Good suggestion. I'll try to re-use existing code as much as possible.

@eddyb I have stored the DefId of imported main in config::EntryFnType::EntryImported. For type check, I was trying to call existing function:

rust/src/librustc_typeck/lib.rs

Lines 178 to 180 in 5d0631a

	fn check_main_fn_ty<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>,
	main_id: ast::NodeId,
	main_span: Span) {

This function requires a ast::NodeId as the parameter. I tried to get the NodeId from DefId as below:

                if let Some(node_id) = tcx.hir.as_local_node_id(*def_id) {
                    check_main_fn_ty(tcx, node_id, *def_id, *sp);
                } else {
                    span_bug!(*sp, "NodeId of `main` is not found");
                }

Then I encountered the problem: as_local_node_id returns None in cross-crate case.

This is my first pull request in the rust compiler, and I must have made some mistakes somewhere due to lack of knowledge of rustc internal.

[eddyb]

@F001 You should go the other way around and change the current code to use DefIds more.
In fact, you can do all of that as a refactor PR without introducing the new feature, just to make the PR that does introduce the feature much smaller.

[F001]

@eddyb Thanks. I'll close this PR later, and split it into 2 PRs.

But in order to refactor check_main_fn_ty, I still have to address the original question first.

The main problem is that this function uses hir::map::Map::find(&self, NodeId) -> Option<Node<'hir>> to get the actual hir::map::Node, and then the generics check can be done.

When I was trying to use DefId as the argument of the function check_main_fn_ty, the only way I know is calling tcx.hir.as_local_node_id(def_id) first and then using tcx.hir.find(node_id). However, this doesn't work in cross-crate case.

In other words, I can't find a way to do the refactoring to use DefId replace NodeId in check_main_fn_ty.

Finally, the question still exists. How can I get the foreign function's signature from DefId ?

[eddyb]

You'll have to work with tcx.generics_of(def_id) and tcx.type_of(def_id). May need to also use tcx.describe_def(def_id) to make sure it's a function to begin with?

[F001]

@eddyb Thanks for the information. I'll have a try later. This PR can be closed now.

[petrochenkov]

@jonas-schievink

If we adopt the "the item named main is the program's main function" model this would be entirely consistent.

I agree that such "resolution-based" formulation (not even mentioning reexports) would be better.

• Resolve path crate::main (with all idents having non-macro contexts) using usual name resolution and whatever is found is our main.
  This resolution can be done during lowering to HIR, so we can just keep main in HIR as an Option<DefId> field for later type checking.