libsyntax: Change ~[T] to Vec<T>.
#12637
Conversation
| cx.cfg(), | ||
| tts.iter() | ||
| .map(|x| (*x).clone()) | ||
| .collect()); |
There was a problem hiding this comment.
This is a rather unfortunate pattern. Shouldn't there be something like tts.to_vec() or Vec::from_slice(tts)?
There was a problem hiding this comment.
It's just transitionary. I don't really want to add methods to Vec that will persist for only a week or so.
|
I'm curious, but what were some of the good/bad parts of this conversion? With future traits we plan on implementing, do you think that this is an adequate replacement for I'm also curious if there are patterns that were concise previously but verbose now. There seem to be lots of spots in this diff which have gotten more verbose, but most of them look like they could be reduced. I commented on a few places (obviously just spot checking), and I just wanted to make sure that there's a relatively nice way of expressing those. Otherwise, let's do this, r=me p=1 |
|
I think this will be an adequate replacement once we have Deref and the old vectors are gone. All the nastiness in this pull request is mostly just because of places where we have to convert from new to old or vice versa. |
|
Sounds good to me, r=me whenever you please. |
|
May I suggest that the commit logs explain why this is being changed? As an outsider, I can only guess now. |
|
#8981 is a big reason for wanting to switch to (In any case, I agree that having a short sentence or two for the background of these changes in the commits is useful: very helpful for history diving in future when all contemporary context is lost.) |
|
Are these kinds of changes being done automatically or manually? If the former, it would be nice to release the software, so that people with Rust codebases can run it too on their own codebase. If the latter, maybe rustc should be enhanced with infrastructure to make writing such translators easy, and then it should be used. Ideally there would be a tool that automatically applies all the changes that ever happened to old Rust code. |
|
@bors: retry |
|
The tool is far too primitive and hacky for public consumption, unfortunately. |
…hable initializers
This commit introduces a check to ensure that the lint won't trigger when the initializer is
unreachable, such as:
```
thread_local! {
static STATE: Cell<usize> = panic!();
}
```
This is achieved by looking at the unpeeled initializer expression and ensuring that the parent
macro is not `panic!()`, `todo!()`, `unreachable!()`, `unimplemented!()`.
fixes rust-lang#12637
changelog: [`threadlocal_initializer_can_be_made_const`] will no longer trigger on `unreachable` macros.
Threadlocal_initializer_can_be_made_const will not trigger for unreachable initializers
This commit introduces a check to ensure that the lint won't trigger when the initializer is unreachable, such as:
```
thread_local! {
static STATE: Cell<usize> = panic!();
}
```
This is achieved by looking at the unpeeled initializer expression and ensuring that the parent macro is not `panic!()`, `todo!()`, `unreachable!()`, `unimplemented!()`.
fixes rust-lang#12637
changelog: [`threadlocal_initializer_can_be_made_const`] will no longer trigger on `unreachable` macros.
r? @alexcrichton