etc,rustdoc: few changes #11989
etc,rustdoc: few changes #11989
Conversation
| @@ -1,7 +1,14 @@ | |||
| #!/usr/bin/env python | |||
| # xfail-license | |||
| # Copyright 2011-2013 The Rust Project Developers. See the COPYRIGHT | |||
There was a problem hiding this comment.
I guess this should be changed to 2014
|
This looks fine to me, I'd want @brson's input to make sure we can just add a license to all these files. |
|
They are all from Rust contributors so I think they are covered by the project-wide license. |
|
IMHO, the license should be updated. From my experience, once one of the fiels is modified, the license should reflect the year it was modified in. IANAL, though! |
|
I don't follow this logic since it would mean that say in 2015 I could update the copyright claim year without changing the files contents but then what's the point of a claim by-years if it doesn't reflect the actual contents? -- |
|
@adridu59: There's no reason to consider each file an individual work. The relevance of the date is when the copyright on the work will expire, so giving it as a range doesn't have any meaning. I don't think there would be any issue with updating every single one to the current year without an initial date, but it would have to be run by Mozilla's lawyers. |
|
@thestinger Well, the GNU guidelines state otherwise. |
|
From the link you gave:
The per-file copyright notice can just be a summary of the copyright across the whole work. Rust is already just including a reference to the list of copyright holders (all contributors) and the real license file. Third party projects included in the tree need to be dealt with separately, but there's no reason for each Rust file to be an independent work. It's just needless complexity. |
|
I feel comfortable adding the license header to these files - they've been around for a long time and are by contributors who are already contributing under the correct license, should have been converted long ago but weren't. There isn't much risk here. Regarding dates, I've been told that the declared copyright date has very little legal weight, partly because it is completely obvious who wrote the code and when based on the project history. The advice I've been given is to just make a best effort and don't worry too much about whether a file says '2013', '2014' or '2013-2014'. Personally, I never bother to update dates when I edit a file. |
|
@adridu59 If you are interested in other tasks along these lines, #4534 is about making licenseck.py check more files. In particular we don't check the license on the test suite. |
|
I managed to seriously confuse bors, and I think that he'll pick up on this next, but to be extra sure, @adridu59 could you push a rebase on the current master? |
|
@alexcrichton I rebased about 50 minutes ago, shall I do it again? |
|
Yeah just to get rid of the bors merge commit (sorry about that) |
|
@alexcrichton It's there! |
|
I interrupted the last set of tests because I believe that they were timing out and #12054 should fix the timeout. |
fix: Fix panics on GATs involving const generics This workaround avoids constant crashing of rust analyzer when using GATs with const generics, even when the const generics are only on the `impl` block. The workaround treats GATs as non-existing if either itself or the parent has const generics and removes relevant panicking code-paths. Fixes rust-lang#11989, fixes rust-lang#12193
Closes #11985
Closes #4533
@huonw, @alexcrichton