Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent storing and passing DST values #13376

Closed
nrc opened this issue Apr 7, 2014 · 1 comment · Fixed by #13715
Closed

Prevent storing and passing DST values #13376

nrc opened this issue Apr 7, 2014 · 1 comment · Fixed by #13715

Comments

@nrc
Copy link
Member

nrc commented Apr 7, 2014

We must forbid storing or passing DST values. I.e., DST values may not be l-values.

The following should be illegal:

fn g<type X>(x: X) {...}
fn f(x: ~[T]) {
    let y = *x; //~ERROR lvalue is dynamically sized
    g(*x); //~ERROR lvalue is dynamically sized
}

I think we can enforce this by preventing storage locations having DST, rather than checking de-references.

Note that pointers to DST values are themselves sized, so may be lvalues. As a follow-up, we may allow DST values to be passed as arguments, but that will involve some pretty gross hacks.

We already prevent DST values being stored in fields.

@nrc nrc mentioned this issue Apr 7, 2014
23 tasks
@nrc
Copy link
Member Author

nrc commented Apr 7, 2014

assigned to me;
cc @nikomatsakis

nrc added a commit to nrc/rust that referenced this issue Apr 23, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 18, 2022
…defaults, r=Veykril

internal: Add `GenericParamList::to_generic_args` and `{TypeParam,ConstParam}::remove_default` APIs

Also fixes `generate_impl` not removing the default const param value, though it seems that no one has encountered or reported that issue yet 😅

This initially started out as refactoring `utils::generate_impl_text_inner` to understand it better (which was the reason for adding `{TypeParam,ConstParam}::remove_default`), but ended up also finding another place that needed `GenericParamList::to_generic_args`, hence its addition in here.
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 7, 2024
new lint: `source_item_ordering`

changelog: [`source_item_ordering`]: Introduced a new restriction lint that checks the ordering of items in Modules, Enums, Structs, Impls and Traits.

From the written documentation:

> Why restrict this?
> Keeping a consistent ordering throughout the codebase helps with working as a team, and possibly improves maintainability of the codebase. The idea is that by defining a consistent and enforceable rule for how source files are structured, less time will be wasted during reviews on a topic that is (under most circumstances) not relevant to the logic implemented in the code. Sometimes this will be referred to as "bike-shedding".
>
> Keep in mind, that ordering source code alphabetically can lead to reduced performance in cases where the most commonly used enum variant isn't the first entry anymore, and similar optimizations that can reduce branch misses, cache locality and such. Either don't use this lint if that's relevant, or disable the lint in modules or items specifically where it matters. Other solutions can be to use profile guided optimization (PGO), or other advanced optimization methods.

I tried to build it as configurable as possible, as such a highly opinionated lint should be adjustable to personal opinions.

I'm open to any input and will be available both here and on the zulip for communication. In the meantime I'll be testing this lint against my own code-bases, which I've (manually) kept ordered with the default config, to see how well it works in practice.

And lastly, a big thanks to the community for making clippy the best linter there is!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant