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

How to exclude generated files? #399

Open
Lysxia opened this issue Oct 30, 2020 · 4 comments
Open

How to exclude generated files? #399

Lysxia opened this issue Oct 30, 2020 · 4 comments
Labels
config ⚙️ Runtime configuration question Further information is requested

Comments

@Lysxia
Copy link

Lysxia commented Oct 30, 2020

I'm using Happy to generate .hs files from .y files, and stan reports errors in the .hs file (notably, Happy-generated files use (!!)) that I would like to exclude from reports.

How can I exclude that file?

Is that currently possible? The problem is that apparently you're supposed to report the path to the .hs file relative to the root of the project, but generated files don't have a stable location. The path to the file shown in the report is the absolute path on my filesystem, going into the dist-newstyle/ directory (see picture). One way would be to have a way to ignore any file whose path ends with MyLib/Parser.hs, rather than matching a relative path exactly.

Screenshot_2020-10-30 Stan Report

@vrom911 vrom911 added config ⚙️ Runtime configuration question Further information is requested labels Nov 2, 2020
@vrom911
Copy link
Member

vrom911 commented Nov 2, 2020

@Lysxia if I understand you correctly, you need to exclude the whole folder of dist-newstyle?
This is possible to do with:

[[check]]
type = "Exclude"
directory = "dist-newstyle/"
filter = "all"

@Lysxia
Copy link
Author

Lysxia commented Nov 2, 2020

Thanks! It seems I have to give the whole prefix, "dist-newstyle/" does not suffice:

directory = "/home/..../mylib/dist-newstyle"

Also this seems overly specific to Cabal. Stack users would then want to exclude .stack-work. It is at the same time quite coarse grained. What do you think of a way to match filepaths by their suffixes, so one could write files = "*/Parser.hs" for instance? I can try to work on a PR.

@vrom911
Copy link
Member

vrom911 commented Nov 2, 2020

Sure, this sounds like a great idea, and there is a use-case for that.
I think we can introduce globs to our configs.

Stan itself is working with the relative paths, so it depends on where you call Stan from (but note, that Stan is also looking for the .cabal file).
I assume that that full path with a prefix is some work of the HIE as we are taking the pathname from there, and for generated files, it seems to add the whole prefix 🤔

@german1608
Copy link

I was taking a look at this while working on chshersh/iris#64, and as @vrom911 pointed out, HIE is putting the absolute path in the case of generated files:

Screen Shot 2022-10-03 at 9 16 51 PM

After brainstorming a little bit, I come up with the following ideas. Let me know your thoughts so I can tackle this issue :)

  1. Ignore the files that are in a known set of folders. We could ignore anything that has .stack-work, or .dist-newstyle on it.
  2. ScopeDirectory would also check for the directory with the current working dir preppended to it:

    stan/src/Stan/Config.hs

    Lines 212 to 225 in c8560bd

    where
    -- TODO: can be implemented efficiently, but the more efficient
    -- implementation is required only if the @configRemoved@ can have
    -- >= 1K entries
    notRemoved :: FilePath -> Bool
    notRemoved path = all (isNotInScope path) configRemoved
    isNotInScope :: FilePath -> Scope -> Bool
    isNotInScope path = \case
    ScopeFile file -> path /= file
    ScopeDirectory dir -> not $ isInDir dir path
    ScopeAll -> False
    {- | Convert the list of 'Check's from 'Config' to data structure that
  3. Add globs to the config, as suggested by @Lysxia

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
config ⚙️ Runtime configuration question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants