Olá Habr! Apresento a você a tradução do artigo "The Rust Release Team" Announcing Rust 1.34.0 " .
A equipe de desenvolvimento do Rust tem o prazer de anunciar o lançamento de uma nova versão do Rust, 1.34.0. Rust é uma linguagem de programação que permite a todos criar software confiável e eficiente.
Se você possui uma versão anterior do Rust instalada usando rustup, para fazer o upgrade do Rust para a versão 1.34.0, basta fazer o seguinte:
$ rustup update stable
Se você ainda não instalou o rustup, poderá instalá-lo na página correspondente do nosso site.
O que está incluído na versão estável 1.34.0
A grande melhoria deste release é o suporte a registros de carga alternativos. O lançamento também inclui suporte ? nos testes de documentação, algumas melhorias no #[attribute(...)] e TryFrom estabilização TryFrom . Leia sobre as principais coisas ou consulte as notas de versão detalhadas para obter mais informações.
cargo alternativos de cargo
Antes da versão 1.0, o Rust tinha um registro público, crates.io . As pessoas publicaram caixas usando cargo publish e as conectaram facilmente na seção [dependencies] do Cargo.toml .
No entanto, nem todo mundo quer publicar suas caixas no crates.io. As pessoas que apoiavam projetos de código fechado não podiam usar o crates.io e, em vez disso, precisavam especificar git ou path nas dependências. Não há nada parecido com isso para pequenos projetos, mas se sua organização possui muitas caixas de código fechado, você perde os benefícios do suporte à versão, disponível em crates.io.
A partir desta versão, a Cargo pode suportar registros alternativos. Esses registros coexistem com o crates.io, para que você possa escrever programas que dependam do crates.io e do seu registro. No entanto, os subracks crates.io não podem depender de um registro externo.
Para usar registros alternativos, você deve adicionar as seguintes linhas ao .cargo/config . Este arquivo pode estar no seu diretório pessoal ( ~/.cargo/config ) ou no diretório do pacote.
[registries] my-registry = { index = "https://my-intranet:8080/git/index" }
Adicionar dependência de um registro alternativo é fácil. Ao especificar a dependência no Cargo.toml , use a chave do registry para que o Cargo saiba que deseja receber a caixa do registro alternativo:
[dependencies] other-crate = { version = "1.0", registry = "my-registry" }
Como autor da caixa, se você deseja publicar sua caixa em um registro alternativo, a primeira coisa a fazer é salvar o token de autenticação em ~/.cargo/credentials usando o comando cargo login :
cargo login --registry=my-registry
Em seguida, você pode usar o sinalizador --registry para especificar o registro no qual o rack será publicado:
cargo publish --registry=my-registry
Sobre como você pode executar seu próprio registro, você pode encontrar na documentação .
? em testes de documentação
A RFC 1937 estava propondo adicionar suporte ao operador ? em fn main() , #[test] funções e testes de documentação, permitindo que eles retornem a Option<T> ou Result<T, E> onde a opção com erro resulta em um código de terminação diferente de zero no caso de fn main() ou um teste descartado no caso de testes .
O suporte em fn main() e #[test] foi implementado por um longo tempo . No entanto, o suporte nos testes de documentação foi limitado aos testes nos quais fn main() explicitamente presente.
? suporte completo foi adicionado nesta versão ? em testes de documentação. Agora você pode escrever na sua documentação testando isto:
Na parte inferior do teste de documentação, você ainda precisa indicar o tipo de erro que será usado.
Suporte para fluxo de token personalizado nos atributos do usuário
Macros de procedimento no Rust podem definir os atributos do usuário que eles usam. Até agora, esses atributos eram limitados a árvores e literais de caminho, de acordo com a seguinte sintaxe:
#[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))]
Diferentemente das macros de procedimento, esses atributos auxiliares não podiam aceitar um fluxo arbitrário de tokens no delimitador, e é por isso que você não pode escrever #[range(0..10)] ou #[bound(T: MyTrait)] . Racks de macros procedurais usavam cadeias de caracteres para sintaxe como esta, por exemplo #[range("0..10")] .
Com esta versão, os atributos personalizados #[attr($tokens)] permitem o uso de tokens arbitrários em $tokens , correspondendo-os de acordo com as macros. Se você é o autor de uma caixa de macro de procedimentos, verifique se as seqüências de caracteres são usadas na sintaxe dos atributos do usuário e se podem ser substituídas por um fluxo de tokens.
TryFrom e TryInto
As TryInto e TryInto foram estabilizadas para suportar erros de conversão de tipo.
Por exemplo, from_be_bytes e métodos relacionados de tipos inteiros recebem uma matriz, mas os dados geralmente são lidos através de fatias. A conversão manual entre fatias e matrizes é entediante. Com novas características, isso pode ser feito na mesma linha que .try_into() .
let num = u32::from_be_bytes(slice.try_into()?);
Para conversões que não podem falhar, como u8 a u32 , o tipo Infallible é adicionado. Devido a isso, o TryFrom implementado automaticamente para tudo que implementa a característica From . No futuro, esperamos tornar o Infallible alias para o ! (nunca)
fn before_exec preterido em favor de unsafe fn pre_exec
Em sistemas tipo Unix, a CommandExt::before_exec permitiu agendar um fechamento antes da exec .
Esse fechamento foi realizado no contexto do processo filho após o garfo. Isso significa que recursos, como descritores de arquivos e áreas de memória, podem ser duplicados. Em outras palavras, você pode obter uma cópia de um valor que não seja do tipo Copy em diferentes processos, enquanto o original permaneceria no pai. Isso pode levar a um comportamento indefinido e quebrar as bibliotecas que sugerem a ausência de duplicação .
Portanto, a função before_exec deve ser marcada como unsafe . Nesta versão, marcamos fn before_exec obsoleto em favor de unsafe fn pre_exec . Ao chamar CommandExt::pre_exec você precisa garantir que o fechamento não viole os invariantes da biblioteca criando duplicatas inválidas. Se você fornecer uma biblioteca que está em uma situação semelhante antes before_exec , pense em obsolescência e forneça uma alternativa unsafe .
Estabilização de bibliotecas
Na versão 1.34.0, o conjunto de tipos inteiros atômicos assinados e não assinados foi expandido, começando com 8 bits ( AtomicU8 ) e terminando com 64 bits.
Inteiros não assinados que não sejam NonZeroU8 , como o NonZeroU8 foram estabilizados anteriormente . Graças a isso, a Option<NonZeroU8> é do mesmo tamanho que u8 . Versões assinadas como NonZeroI8 estabilizadas nesta versão.
As funções iter::from_fn e iter::successors estabilizadas. O primeiro permite criar um iterador a partir do FnMut() -> Option<T> . Para recuperar elementos iterativamente de um vetor, agora você pode escrever from_fn(|| vec.pop()) . Enquanto isso, a segunda função cria um novo iterador, em que cada próximo elemento é calculado com base no anterior.
Além disso, as seguintes APIs foram estabilizadas:
Veja as notas de versão detalhadas para mais detalhes.